Ex Parte Verbeke et al

Board of Patent Appeals and Interferences

Mar 16, 2010

10869664 (B.P.A.I. Mar. 16, 2010)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte JEROME M. VERBEKE and NEELAKANTH M. NADGIR
____________

Appeal 2009-004231
Application 10/869,664
Technology Center 2100
____________

Decided: March 16, 2010
____________

Before JOHN A. JEFFERY, HOWARD B. BLANKENSHIP, and
JAY P. LUCAS, Administrative Patent Judges.

JEFFERY, Administrative Patent Judge.

DECISION ON APPEAL
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1-58. We have jurisdiction under 35 U.S.C. § 6(b). We
affirm-in-part.

Appeal 2009-004231
Application 10/869,664

2
STATEMENT OF THE CASE
Appellants invented a system that dynamically configures replicated
database servers. Specifically, lost server nodes can be automatically
replaced with a “pool node” to maintain a desired level of replication. See
generally Abstract; Spec. 6-12; Figs. 3-4. Claim 1 is illustrative:
1. A replicated database system, comprising:

a plurality of server nodes each comprising a replica of a database,
wherein the replicas of the database on the server nodes are concurrently
accessible to service requests to the database; and

one or more pool nodes, wherein each of the one or more pool nodes
is capable of becoming a server node in the replicated database system;

wherein the plurality of server nodes is configured to:

determine whether a new server node is needed in the plurality of
server nodes; and

recruit one of the pool nodes as the new server node in the plurality of
server nodes.

The Examiner relies on the following as evidence of unpatentability:
Li Gong, Project JXTA: A Technology Overview, Sun Microsystems, Inc.,
1-10, Apr. 25, 2001 (“Gong”).

Jerome Verbeke et al., Framework for Peer-to-Peer Distributed Computing
in a Heterogeneous, Decentralized Environment, Sun Microsystems, Inc.,
1-13, 2002 (“Verbeke”).1

1 Although the Verbeke reference is undated, we nevertheless cite the date
indicated by the Examiner (Ans. 3)—a date that is undisputed.
Appeal 2009-004231
Application 10/869,664

3
THE REJECTION
The Examiner rejected claims 1-58 under 35 U.S.C. § 103(a) as
unpatentable over Gong and Verbeke. Ans. 3-28.2

CLAIM GROUPING
Appellants argue the following claim groups separately: (1) claims 1,
6, 12-16, 20, 30, 33, 37, 44-48, 50, 57, and 58; (2) claims 2, 17, 34, and 47;
(3) claims 3, 18, 35, and 48; (4) claims 4, 19, 36, and 49; (5) claims 5, 38,
and 51; (6) claims 7, 21, 39, and 52; (7) claims 8, 22, 40, and 53; (8) claims
9, 23, 41, and 54; (9) claims 10, 24, 31, 42, and 55; (10) claims 11, 25, 43,
and 56; (11) claims 26 and 27; (12) claim 28; (13) claim 29; and (14) claim
32. See App. Br. 12-31. We accept these groupings, but due to their
dependencies, we group claims 5 and 6 with claim 4, (2) claim 13 with claim
11; (3) claim 20 with claim 19; (4) claim 37 with claim 36; (5) claim 50 with
claim 49; (6) claims 47 and 48 with claims 2 and 3, respectively.
Accordingly, we select claims 1-5, 7-11, and 26 as representative of groups
(1)-(11), respectively. See 37 C.F.R. § 41.37(c)(1)(vii).

CONTENTIONS
Regarding representative claim 1, the Examiner finds that Gong and
Verbeke collectively teach (1) plural “server nodes” that each have a
database replica, and (2) “pool nodes” that can become a “server node” as
claimed. Ans. 4-6, 29-31. According to the Examiner, Verbeke’s “server

2 Throughout this opinion, we refer to (1) the Appeal Brief filed November
26, 2007; (2) the Examiner’s Answer mailed February 20, 2008; and (3) the
Reply Brief filed April 19, 2008.
Appeal 2009-004231
Application 10/869,664

4
nodes” (i.e., task dispatchers) can determine whether a new “server node”
(task dispatcher) is needed, and recruit a “pool node” (i.e., a worker) as the
new “server node” as claimed. Id.
Appellants argue that Gong’s mirrored disk system does not teach or
suggest a replicated database system where the database replicas are
concurrently accessible to service requests, let alone teach pool nodes
capable of becoming server nodes for such a system as claimed. App. Br.
12-14. Appellants add that Verbeke likewise fails to disclose a replicated
database system, but rather a grid computing system for parallelizing
computations to solve problems. App. Br. 15; Reply Br. 3-4. According to
Appellants, Verbeke’s task dispatchers merely assign tasks to workers in a
grid computing system, and therefore are not analogous to the recited server
nodes in a replicated database system. App. Br. 14-16; Reply Br. 6-7.
Lastly, Appellants contend that there is no reason to combine the
references to arrive at the claimed invention since Verbeke already
incorporates peer computing and JXTA,3 and therefore the combination
would allegedly not result in any change to the prior art, let alone result in
the claimed invention. App. Br. 17; Reply Br. 8-9.
Regarding representative claim 2, Appellants argue that Verbeke’s
task dispatchers are not server nodes that detect that one of the server nodes
has gone down. App. Br. 17-18; Reply Br. 9.

3 “JXTA technology is a set of open protocols that allow any connected
device on the network ranging from cell phones and wireless PDAs to PCs
and servers to communicate and collaborate in a P2P [peer-to-peer]
manner.” Spec. 1:27-29.
Appeal 2009-004231
Application 10/869,664

5
Regarding representative claim 3, Appellants argue that Verbeke does
not teach or suggest detecting that one of the servers that has gone down has
not communicated with the other server nodes for a specified number of
intervals. App. Br. 18-19; Reply Br. 9.
Regarding claim 4, Appellants argue that Verbeke does not teach or
suggest at least one of the server nodes broadcasting a message to plural
pool nodes requesting the pool nodes to volunteer to become the new server
node. App. Br. 19-20; Reply Br. 10.
Regarding representative claim 7, Appellants argue that Verbeke does
not teach or suggest that to recruit one of the pool nodes as the new server
node, at least one of the server nodes is configured to replicate the database
to the recruited pool node. App. Br. 22-23; Reply Br. 11.
Regarding representative claim 8, Appellants argue that the cited prior
art does not teach or suggest that to recruit one of the pool nodes as the new
server node, at least one of the server nodes provides software and
configuration information to the recruited pool node to enable it to operate
as a server node as claimed. App. Br. 24-25; Reply Br. 11.
Regarding claim 9, Appellants argue that the cited prior art does not
teach or suggest that to determine that a new server node is needed, the
server nodes are configured to determine that demand on the replicated
database has increased above a demand threshold. App. Br. 25-26; Reply
Br. 11-12.
Regarding claim 10, Appellants argue that the cited prior art does not
teach or suggest determining demand on the replicated database decreasing
below a demand threshold and releasing a selected server node to become a
pool node. App. Br. 26-27; Reply Br. 12.
Appeal 2009-004231
Application 10/869,664

6
Regarding representative claim 11, Appellants argue that the cited
prior art does not teach or suggest receiving from one or more other server
nodes differences between the broadcast current status of the server node’s
database replica and the current status of the database replica on one or more
other server nodes, and updating the server node’s replica according to the
received differences. App. Br. 27-29; Reply Br. 13-14.
Regarding representative claim 26, Appellants argue that the cited
prior art does not teach or suggest stopping execution of a current process on
a pool node responsive to a received broadcast message, let alone starting
execution of a replicated database server process on the pool node
responsive to the received message. App. Br. 29-30; Reply Br. 13-14.
The issues before us, then, are as follows:

ISSUES
1. Under § 103, has the Examiner erred by finding that Gong and
Verbeke collectively would have taught or suggested:
(1) plural server nodes comprising database replicas that are
concurrently accessible to service requests to the database as recited in claim
1?
(2) at least one pool node capable of becoming a server node in the
replicated database system as recited in claim 1?
(3) the server nodes can (a) determine whether a new server node is
needed, and (b) recruit a pool node as the new server node as recited in
claim 1?
Appeal 2009-004231
Application 10/869,664

7
(4) the server nodes are configured to detect that one of the server
nodes has gone down and is replaced with the new server node as recited in
claim 2?
(5) the server nodes are configured to detect that one of the servers
that has gone down has not communicated with the other server nodes for a
specified number of intervals as recited in claim 3?
(6) at least one of the server nodes broadcasting a message to plural
pool nodes requesting the pool nodes to volunteer to become the new server
node as recited in claim 4?
(7) to recruit one of the pool nodes as the new server node, at least
one of the server nodes is configured to replicate the database to the
recruited pool node as recited in claim 7?
(8) to recruit one of the pool nodes as the new server node, at least one
of the server nodes provides software and configuration information to the
recruited pool node to enable it to operate as a server node as recited in
claim 8?
(9) to determine that a new server node is needed, the server nodes are
configured to determine that demand on the replicated database has
increased above a demand threshold as recited in claim 9?
(10) determining demand on the replicated database decreasing below
a demand threshold and releasing a selected server node to become a pool
node as recited in claim 10?

Appeal 2009-004231
Application 10/869,664

8
(11)(a) receiving from one or more other server nodes differences
between the broadcast current status of the server node’s database replica
and the current status of the database replica on one or more other server
nodes, and (b) updating the server node’s replica according to the received
differences as recited in claim 11?
(12)(a) stopping execution of a current process on a pool node
responsive to a received broadcast message, and (b) starting execution of a
replicated database server process on the pool node responsive to the
received message as recited in claim 26?

2. Is the Examiner’s reason to combine the teachings of Gong and
Verbeke supported by articulated reasoning with some rational underpinning
to justify the Examiner’s obviousness conclusion?

FINDINGS OF FACT (FF)
1. Gong discloses “JXTA” technology that enables interconnected
peers in a peer-to-peer network (P2P)4 to easily locate and communicate
with each other seamlessly across different P2P systems and communities.
Gong, at 1-2. See also n.3, supra, of this opinion (defining JXTA).
2. Gong describes services provided by various P2P systems,
including sharing music files and generic files. Gong, at 2.
3. Gong notes that typical P2P software architectures include (1) a
service layer dealing with indexing, searching, and file sharing, and (2) an
application layer including storage systems. Gong, at 3.

4 For simplicity, we abbreviate “peer-to-peer” as “P2P” throughout this
opinion.
Appeal 2009-004231
Application 10/869,664

9
4. Gong describes an exemplary scenario using JXTA where different
engineering groups could create a storage peer group. In this system, each
engineering group’s disks could discover each other automatically and
mirror data using their spare capacity. Gong, at 11.
5. Verbeke discloses a framework for P2P distributed computing in a
decentralized environment. This framework enables solving large-scale
problems that feature coarse-grained parallelization, and allows for a
dynamic and decentralized organization of computational resources.
Verbeke, at 1.
6. Verbeke’s distributed computing framework comprises the
following peer groups: (1) monitor group; (2) worker group; (3) task
dispatcher group; and (4) repository group. Verbeke, at 2.
7. The task dispatcher group distributes individual tasks to workers,
and the worker group performs the computations for a particular job. The
repository group serves as a cache for code and data. Verbeke, at 2-3.
8. After the task dispatcher distributes the appropriate code and tasks
to the worker, the worker (1) performs the task, and (2) returns the result to
the task dispatcher. Verbeke, at 4.
9. Verbeke notes that it is necessary to have redundant task
dispatchers in task dispatcher peer groups. Thus, by having two task
dispatchers keep each other up to date with the latest results they have
received from workers, the information is not lost if one task dispatcher
becomes inoperative. Verbeke, at 5; Fig. 2.
10. Task dispatchers in a peer group communicate by sending each
other messages at regular time intervals (i.e., during “heartbeats”). When
Appeal 2009-004231
Application 10/869,664

10
task dispatchers receive new results from a worker, they send them to the
other task dispatcher to keep a redundant copy of these results. Verbeke, at
5; Fig. 2.
11. If, however, a “task dispatcher in the same peer group realizes
that his redundant colleague is missing, it will invite a worker requesting a
task to execute the task dispatcher code in his peer group, transforming a
regular worker into a task dispatcher.” Verbeke, at 5-6; Fig. 2.
12. The caption for Verbeke’s Figure 2 is as follows: “Fig. 2. Worker
node assumes the role of task dispatcher when the latter is disrupted.”
Verbeke, at 5; Fig. 2.
13. Appellants’ Specification notes that replicating an entire database
across two or more servers on a network helps to avoid potentially losing
part of a distributed database. Spec. 4:11-16.
14. “[T]he term ‘pool of nodes’ is used herein as a general term to
describe any collection or set of nodes available to become server nodes, and
is not meant to imply any particular structure or grouping of the nodes.”
Spec. 16:15-17.
15. “In one embodiment, the peer-to-peer platform may be the JXTA
platform. In these embodiments, pool 250 may be a peer group in a peer-to-
peer network, and the server and pool nodes may be peer nodes. Note that
clients 220 may also be peer nodes in the peer-to-peer network.” Spec.
17:25-29.
16. Figure 19 of Appellants’ disclosure illustrates a worker node
assuming the role of a task dispatcher according to one embodiment. Spec.
10:8-9; Fig. 19. See generally Spec. 42:24–45:15.
Appeal 2009-004231
Application 10/869,664

11
17. Verbeke notes that the number of task dispatchers in a peer group
is not limited to two, but can be higher. Verbeke, at 6.

PRINCIPLES OF LAW
To be patentable under § 103, an improvement must be more than the
predictable use of prior art elements according to their established functions.
KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007).

ANALYSIS
Claims 1, 12, 14-16, 30, 32, 33, 44-46, 51, 53, 57, and 58
We begin by construing a key disputed limitation of representative
claim 1 which calls for a replicated database system. We emphasize the
term “database” for its construction is key to resolving this dispute.
The Federal Circuit has defined “database” quite broadly, namely
“any electronically-stored collection of data[.]” In re Comiskey, 554 F.3d
967, 981 (Fed. Cir. 2009) (citing Alan Freedman, The Computer Glossary
90 (8th ed. 1998)). Based on this definition, we construe a “replicated
database system” as one that replicates (i.e., produces a replica of) any
electronically-stored collection of data.
With this construction, we turn to the cited prior art. Although the
Examiner’s Answer is not a model of clarity, the Examiner nevertheless
relies extensively on Verbeke’s peer-based distributed computing
functionality for teaching or suggesting various limitations of claim 1. In
this regard, the Examiner apparently equates (1) Verbeke’s task dispatchers
Appeal 2009-004231
Application 10/869,664

12
to the recited “server nodes,” and (2) Verbeke’s workers to the recited “peer
nodes.” See Ans. 31 (referring to one of the pool nodes as a “worker group,”
and the plural server nodes as a “task dispatcher group”).5
We see no error in this interpretation. First, we see no reason why
Verbeke’s task dispatchers cannot be considered “server nodes,” particularly
in view of their task and code distribution functions (FF 8), as well as their
ability to periodically exchange data (i.e., received results from workers)
with counterpart task dispatchers (FF 9-10).
Notably, nothing in claim 1 precludes this received result data that is
exchanged among task dispatchers as constituting a “database,” for this data
amply meets the Comiskey’s definition noted above, namely “any
electronically-stored collection of data.” See Comiskey, 554 F.3d at 981.
And each of these task dispatchers (“server nodes”) would comprise a
replica of that “database” by virtue of their periodically sharing their results
with each other for redundancy. See FF 10. Simply put, these redundant
copies of the shared results constitute replicas of that “database”—replicas
that are currently accessible to service requests to the database by at least the
task dispatchers. See FF 9-10.
Nor do we find error in the Examiner’s equating Verbeke’s workers
with the recited “pool nodes.” Not only does Verbeke actually refer to
workers as “nodes” in connection with Figure 2 (FF 12), the fact that a

5 But see Ans. 5, 29, 30 (referring to “monitor groups” as server nodes); Ans.
4 (referring to “peer-to-peer systems” as server nodes and “peer groups” as
pool nodes). To the extent that these interpretations vary from the
Examiner’s interpretation discussed in our opinion, we deem this
inconsistency harmless for we confine our discussion to one of these
apparently alternative interpretations.
Appeal 2009-004231
Application 10/869,664

13
worker can be transformed into task dispatcher to assume its functions when
a task dispatcher is disrupted (FF 11-12) only bolsters our conclusion that
worker “nodes” in Verbeke reasonably constitute “pool nodes.” Notably,
the operational task dispatcher not only determines that a new server node (a
replacement task dispatcher) is needed under this condition, it also invites
(i.e., recruits) the worker to become that node. See FF 11.
Appellants’ contention that this functionality pertains to only one task
dispatcher and not plural server nodes as claimed (Reply Br. 7-8) is
unavailing. Even assuming, without deciding, that only one task dispatcher
invites a particular worker to become a task dispatcher when it determines a
counterpart task dispatcher becomes inoperative, skilled artisans would have
nevertheless understood that the other task dispatchers in the group would
likewise have commensurate functionality (including the failed task
dispatcher). See FF 9-11. Notably, all claim 1 requires in this regard is that
the server nodes are configured to perform these functions — a limitation
fully met by the commensurate functionality of each task dispatcher within
the group—even a failed task dispatcher in that group. See id. In any event,
there can be more than two task dispatchers in a peer group. FF 17.
In reaching our conclusion, we note the Examiner’s interpretation
fully comports with Appellants’ somewhat general description of “pool
nodes” in the Specification, namely “any collection or set of nodes available
to become server nodes” (FF 14)—a description that Appellants further
qualify as “not mean[ing] to imply any particular structure or grouping of
the nodes.” Id. That Appellants’ own disclosure includes an embodiment
with worker nodes and task dispatchers that is strikingly similar to
Appeal 2009-004231
Application 10/869,664

14
Verbeke’s Figure 2 only bolsters our conclusion that the Examiner’s
interpretation noted above is reasonable in light of the Specification.
Compare FF 12 with FF 16.
Although we find the Examiner’s reliance on Gong merely cumulative
in this regard, we nevertheless see no error in the Examiner’s reliance on
Gong’s peer-to-peer file-sharing capabilities (FF 1-4)—functionality that at
least suggests replicating data among peers. Applying Verbeke’s teachings
to such a P2P system is tantamount to the predictable use of prior art
elements according to their established functions. KSR, 550 U.S. at 417.
We therefore find the Examiner’s reason to combine the teachings of the
cited references supported by articulated reasoning with some rational
underpinning to justify the Examiner’s obviousness conclusion.
We are therefore not persuaded that the Examiner erred in rejecting
representative claim 1, and claims 12, 14-16, 30, 32, 33, 44-46, 51, 53, 57,
and 58 which fall with claim 1.

Claims 2, 17, 34, and 47
We will also sustain the Examiner’s rejection of claim 2 essentially
for the reasons noted previously. We add that the task dispatcher’s
“realizing” that a redundant task dispatcher is missing (FF 11) at least
suggests detecting that a server node (task dispatcher) has gone down. And
this failed “server node” is replaced with the invited worker (Id.) as noted
previously.
We are therefore not persuaded that the Examiner erred in rejecting
representative claim 2, and claims 17, 34, and 47 which fall with claim 2.

Appeal 2009-004231
Application 10/869,664

15
Claims 3, 18, 35, and 48
We will also sustain the Examiner’s rejection of representative claim
3 essentially for the reasons indicated previously. As the Examiner indicates
(Ans. 9, 33), Verbeke’s task dispatchers communicate with each other at
regular intervals, including exchanging received results to ensure
redundancy. FF 10. And when a task dispatcher realizes its redundant task
dispatcher is missing, it will invite a worker to replace the failed task
dispatcher. FF 11.
Based on this periodic communication between task dispatchers,
ordinarily skilled artisans would have recognized that a task dispatcher’s
“realizing” that another task dispatcher failed could reasonably result from
the task dispatcher’s failure to communicate with its counterpart at a
particular interval. See FF 10-11. Indeed, it is difficult to envision any other
failure detection mechanism given Verbeke’s periodic communications
between task dispatchers. In any event, although it is unclear from Verbeke
how many intervals would result in this determination, we nevertheless find
that such a choice would have been well within the level of ordinarily skilled
artisans.
We are therefore not persuaded that the Examiner erred in rejecting
representative claim 3, and claims 18, 35, and 48 which fall with claim 3.

Claims 4-6, 19, 20, 36, 37, 49, and 50
We will not, however, sustain the Examiner’s rejection of claim 4.
Although Verbeke’s task dispatcher invites a single worker node to replace a
failed task dispatcher under this condition (FF 11-12), we cannot say that
Verbeke broadcasts a message to the pool nodes requesting that they
Appeal 2009-004231
Application 10/869,664

16
volunteer for that replacement. Although the task dispatcher’s “invitation”
suggests that it is requesting a particular worker to volunteer to replace the
failed task dispatcher under this condition (otherwise it would be more than
an invitation (i.e., an offer to accept that invitation)), the Examiner has
simply not shown that the task dispatcher broadcasts such an “invitation” to
other workers as well.
We are therefore persuaded that the Examiner erred in rejecting claim
4, and claims 36 and 49 which recite commensurate limitations. We will
likewise reverse the Examiner’s rejection of dependent claims 5, 6, 37, and
50 for similar reasons.
But we will sustain the Examiner’s rejection of representative claim
19. Unlike claim 4, claim 19 merely requires broadcasting the volunteer
request message to the one or more pool nodes–not necessarily plural pool
nodes. As such, this limitation is reasonably suggested by Verbeke’s task
dispatcher inviting a single worker node to replace a failed task dispatcher as
noted above.
We are therefore not persuaded that the Examiner erred in rejecting
claim 19 and claim 20 which falls with claim 19.

Claims 7, 21, 39, and 52
We will also sustain the Examiner’s rejection of representative claim
7 essentially for the reasons noted previously. Based on Verbeke’s
functionality, ordinarily skilled artisans would have understood that when a
worker is recruited and transformed into a task dispatcher (FF 11-12), it will
then function as such. In this role, this new task dispatcher would at least
periodically receive received worker results from its counterpart task
Appeal 2009-004231
Application 10/869,664

17
dispatchers (i.e., the “database” would be replicated to the new “server
node” (i.e., the recruited worker transformed to a task dispatcher)). See FF
9-12.
We are therefore not persuaded that the Examiner erred in rejecting
representative claim 7, and claims 21, 39, and 52 which fall with claim 7.

Claims 8, 22, 40, and 43
We will also sustain the Examiner’s rejection of representative claim
8 essentially for the reasons noted previously. Based on Verbeke’s
functionality, ordinarily skilled artisans would have understood that by
having an invited worker execute task dispatcher code to transform the
worker into a task dispatcher (FF 11) would have at least suggested
providing software and configuration information to the recruited worker to
enable it to function as a task dispatcher.
We are therefore not persuaded that the Examiner erred in rejecting
representative claim 8, and claims 22, 40, and 43 which fall with claim 8.

Claims 9, 10, 23, 24, 41, 42, 54, and 55
We will not, however, sustain the Examiner’s rejection of claim 9.
Although the Examiner generally refers to the functionality of the monitor
group in Verbeke (Ans. 19, 20, 38) as allegedly teaching the recited demand
threshold level, we fail to see—nor has the Examiner explained—how this
functionality suggests such a threshold, let alone determine that a new server
node (i.e., task dispatcher) is needed when demand exceeds this threshold as
recited in claim 9.
Appeal 2009-004231
Application 10/869,664

18
We reach a similar conclusion regarding claim 10 calling for
determining demand on the replicated database decreasing below a demand
threshold and releasing a selected server node to become a pool node. Here
again, we fail to see—nor has the Examiner explained—how the cited
functionality from Verbeke (Ans. 20-22; 39-40) meets the specific demand
threshold in claim 10, let alone selecting and releasing a server node to
become a pool node as claimed.
We are therefore persuaded that the Examiner erred in rejecting claim
9, and claims 23, 41, and 54 which recite commensurate limitations.
Likewise, we reverse the Examiner’s rejection of claim 10 and claims 24,
42, and 55 which recite commensurate limitations.

Claims 11, 13, 25, 32, and 56
We will, however, sustain the Examiner’s rejection of representative
claim 11 essentially for the reasons noted previously. Based on Verbeke’s
functionality, ordinarily skilled artisans would have understood that the very
act of the task dispatchers sending each other their received results (i.e.,
“database”) would effectively broadcast its current status. See FF 9-10.
Moreover, such an exchange would effectively indicate the differences
between these replicas (albeit not explicitly) and the server node’s replica
would be updated accordingly. See id. We emphasize that nothing in claim
11 precludes overwriting the earlier versions with current versions, since the
differences between these respective versions would be “received” (i.e., via
the newer version) and updating would occur “according to” those
Appeal 2009-004231
Application 10/869,664

19
differences. See id. We reach a similar conclusion regarding claim 32 as
nothing in the claim precludes this updating process from synchronizing the
replicas as claimed.
We are therefore not persuaded that the Examiner erred in rejecting
representative claim 11, and claims 13, 25, and 56 which fall with claim 11.

Claims 26 and 27
We will also sustain the Examiner’s rejection of representative claim
8 essentially for the reasons noted previously. Based on Verbeke’s
functionality, ordinarily skilled artisans would have understood that by
having an invited worker execute task dispatcher code to transform the
worker into a task dispatcher (FF 11), the worker would have stopped
executing its current worker process (i.e., process on the pool node).
Moreover, the worker would have started executing a replicated database
server process on the pool node responsive to the invitation to enable it to
function as a task dispatcher. See id.
We are therefore not persuaded that the Examiner erred in rejecting
representative claim 26, and claim 27 which falls with claim 26.

Claims 28 and 29
Since Appellants’ arguments for claims 28 and 29 are the same as for
claims 7 and 8 (App. Br. 31), we are not persuaded by these arguments for
the reasons indicated previously regarding claims 7 and 8. We therefore will
sustain the Examiner’s rejection of claims 28 and 29.

Appeal 2009-004231
Application 10/869,664

20
CONCLUSION
The Examiner did not err in rejecting claims 1-3, 7, 8, 11-22, 25-29,
30, 32-35, 38-40, 43-48, 51-53, and 56-58 under 35 U.S.C. § 103. The
Examiner, however, erred in rejecting claims 4-6, 9, 10, 23, 24, 31, 36, 37,
41, 42, 49, 50, 54, and 55 under 35 U.S.C. § 103.

ORDER
The Examiner’s decision rejecting claims 1-58 is affirmed-in-part.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv).

AFFIRMED-IN-PART

pgc

MHKKG/Oracle (Sun)
P.O. BOX 398
AUSTIN TX 78767