Ex Parte RantaDownload PDFBoard of Patent Appeals and InterferencesAug 8, 201210502165 (B.P.A.I. Aug. 8, 2012) Copy Citation 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 Copy with citationCopy as parenthetical citation