Ex Parte Ranta

Board of Patent Appeals and Interferences

Aug 8, 2012

10502165 (B.P.A.I. Aug. 8, 2012)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________________

Ex parte JARI RANTA
____________________

Appeal 2009-013132
Application 10/502,165
Technology Center 2100
____________________

Before ERIC S. FRAHM, DENISE M. POTHIER, and DAVID M. KOHUT,
Administrative Patent Judges.

FRAHM, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2009-013132
Application 10/502,165

2
STATEMENT OF THE CASE1
Introduction
Appellant appeals under 35 U.S.C. § 134(a) from a final rejection of
claims 1 and 3-10. Claim 2 has been canceled. We have jurisdiction under
35 U.S.C. § 6(b). We reverse.
Exemplary Claims
Exemplary independent claims 1 and 8 under appeal, with bracketed
numbering, some paragraphing, and emphases added, read as follows:
1. A method for improving the reliability and
performance of a distributed database available on a network,
the distributed database using multiple network nodes and a
search key referring user data,
[1] characterized in that the search key is used as an
argument for a hash function to generate a pseudo-random key
for pointing to an individualized node for storing the user data
in the network, and
[2] characterized in that each record in the database is
stored automatically in at least one primary node and in at least
one secondary node,
[3] hash function values being used to point to the
primary and the secondary nodes, so that data is accessed from
the secondary node in case of failure to access the data from the
primary node.

1 Throughout our decision, infra, we make reference to the Appeal Brief
filed November 6, 2008 (“App. Br.”); the Examiner’s Answer mailed
February 5, 2009 (“Ans.”); and the Reply Brief filed April 6, 2009 (“Reply
Br.”).
Appeal 2009-013132
Application 10/502,165

3
8. A method for storing and accessing information in a
multi-computer environment, the method comprising:
[1] calculating a hash function value of a search key for
the information;
[2] determining a primary node with the hash function
value of the search key;
[3] determining a secondary node from the hash function
value for determining a secondary node for backup;
[4] storing the information in servers in the primary and
the secondary nodes;
[5] accessing the information by calculating the hash
function value of the search key and accessing the node with
the hash function value or with a secondary hash function
value.

Rejection
The Examiner rejected claims 1 and 3-10 under 35 U.S.C. § 102(e)
over Hickman (US 6,523,036 B1). Ans. 4-11.
Appellant’s Contentions
Appellant contends, inter alia, that the Examiner erred in determining
that Hickman anticipates claims 1 and 3-10 because Hickman fails to
disclose limitations [1] and [3] of claim 1 (App. Br. 8-11; Reply Br. 2-5),
and limitation [5] of claim 8 (App. Br. 15-17; Reply Br. 8-9).
More specifically, Appellant contends (App. Br. 8-9) that Hickman
fails to disclose a search key used as an argument for a hash function to
generate a pseudo-random key that points to an individualized node for
storing data in a network, as recited in limitation [1] of claim 1.
Appeal 2009-013132
Application 10/502,165

4
Appellant contends (Reply Br. 4-5) that Hickman fails to use a hash
function to point to a base or node, and instead uses a load balancing
process to select nodes. Appellant asserts (Reply Br. 4-5) that Hickman uses
a hash function to determine which fragments correspond to data objects to
be retrieved or accessed, and fails to disclose using hash function values to
point to primary and secondary nodes as recited in limitation [3] of claim 1.
Appellant also contends (App. Br. 17; Reply Br. 8-9) that Hickman
fails to disclose accessing a node using a hash function value or a secondary
hash function value, as recited in limitation [5] of claim 8.
Issue on Appeal
Based on Appellant’s arguments, the following issue presents itself on
appeal:
Did the Examiner err in rejecting claims 1 and 3-10 as being
anticipated because Hickman fails to teach limitations [1] and [3] in claim 1,
or limitation [5] in claim 8?

ANALYSIS
We agree with the Appellant’s above contentions that Hickman fails
to disclose limitations [1] and [3] of claim 1, and limitation [5] of claim 8.
Hickman discloses a hashing function h(Ki) based on a search key
value Ki which corresponds to a hash bucket containing a fragmented subset
of the database table in database 63 (col. 11, ll. 52-65). Hickman discloses
that the hashing function h(Ki) operates to divide data objects into four
buckets (e.g., 0-3) that contain the data objects (col. 11, ll. 59-63; Fig. 4).
Hickman’s netstore, which is a set of cooperating server machines, is
divided into clusters of server machines so that data, which has been
Appeal 2009-013132
Application 10/502,165

5
partitioned into fragments, can be distributed across the server clusters in
equal amounts (col. 2, ll. 42-48; col. 3, ll. 4-11 and 25-28; col. 11, l. 52 to
col. 12, l. 3). A fragment map 54 is used to determine from which cluster
the data is written to or retrieved (col. 10, ll. 57-64). Hickman discloses that
in this manner, the system provides for “load balancing” of the transactions
across the server clusters (col. 2, ll. 60-62; col. 10, ll. 45-64).
Hickman’s Figure 4 and column 11, lines 54-582 fail to disclose
generating a pseudo-random key for pointing to a node for storing data in the
network as recited in limitation [1] of claim 1. Although Hickman discloses
a hashing function h(Ki) and a search key Ki, it is not clear what value or
element in Hickman constitutes a pseudo-random key that, in turn, is
generated by the search key Ki.
Hickman describes a hashing function h(Ki) based on a search key Ki
(col. 11, ll. 59-63), and a fragment map 54 for pointing to a cluster, base, or
node for storing data (col. 10, ll. 57-64), but is silent with respect to any
pseudo-random key for pointing to a node. Hickman locates nodes using the
fragment map 54 rather than using a key to point to a node. Thus, claim
limitation [1] in claim 1, “the search key is used as an argument for a hash
function to generate a pseudo-random key for pointing to an individualized
node for storing the user data in the network,” is not disclosed by Hickman.
Accordingly, we agree with Appellant (App. Br. 8-9) that Hickman fails to
disclose generating a “pseudo-random key for pointing to an individualized

2 The Examiner relies upon Figure 4 and column 11, lines 54-58 as
disclosing limitation [1] of claim 1, including generation of a
pseudo-random search key (Ans. 4 and 11-12).
Appeal 2009-013132
Application 10/502,165

6
node for storing the user data in the network” as recited in claim 1 (claim 1,
limitation [1]).
Hickman’s column 3, lines 4-113 is also silent as to (a) automatically
storing each record in at least one primary node and in at least one secondary
node, as recited in limitation [2] of claim 1; and/or (b) pointing to a node for
storing data in the network, as recited in limitation [1] of claim 1. Column
3, lines 4-11 describes providing replicas for each machine in a server
cluster to provide high availability, and does not mention storage or pointing
at all.
Hickman fails to disclose that any individual bucket/fragment is
stored in both a primary and a secondary node to provide backup. In other
words, the hashing function h(Ki) only points to one node, base, or cluster.
The Examiner (see Ans. 5 and 8-9) has not sufficiently or reasonably
explained how column 11, lines 54-58 teaches using the hashing function
h(Ki) to point to primary and secondary nodes. We agree with Appellant
(App. Br. 9) that Hickman’s hashing function h(Ki) merely points to
fragments/buckets, and not to primary and secondary bases, nodes, or
clusters.
We agree with Appellant that Hickman’s fragments are not nodes
(Reply Br. 3-4), and thus Hickman fails to disclose using hash function
values to determine a base or node for storing or accessing data (Reply Br.
9). We also agree with Appellant (Reply Br. 5) that Hickman’s column 10,
lines 44-56 discloses that the load balancing function is used to decide which
base (i.e., node) 44, M1, or M2, to access a data record from in a cluster (see

3 The Examiner relies on column 3, lines 4-11 as disclosing limitations [2]
and [3] of claim 1 (Ans. 5).
Appeal 2009-013132
Application 10/502,165

7
Fig. 3). Hickman’s clusters C1 and C2 each contain a pair of bases 44 or
nodes (col. 8, ll. 57-67). According to Hickman’s column 10, lines 56-64, a
fragment map 54 is used to determine from which or to which cluster to
store or access data. The hashing function h(Ki) is used to distribute the data
objects amongst the four buckets 0-3 which correspond to the individual
fragments. However, the fragment map 54, and not the hashing function
h(Ki), is used to point to a cluster, base, or node (see e.g., Fig. 5; col. 10, ll.
45-64). Therefore, Hickman does not disclose using a hashing function to
point to a primary node and/or a secondary node as recited in claim 1 (claim
1, limitation [3]), or accessing a node using hash function values as recited
in claim 8 (claim 8, limitation [5]).
The Examiner has erred in finding that Hickman discloses limitations
[1] and [3] as recited in independent claim 1, and limitation [5] as recited in
in independent claim 8. The remaining claims depend from claims 1 and 8,
and the rejection of these claims is similarly not sustainable.

CONCLUSION
Appellant has established that the Examiner erred in rejecting claims 1
and 3-10 as being unpatentable under 35 U.S.C. § 102(e).

Appeal 2009-013132
Application 10/502,165

8
DECISION
The Examiner's rejection of claims 1 and 3-10 is reversed.

REVERSED

msc