UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD. Unified Patents Inc., Petitioner v.

Transcription

1 UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Unified Patents Inc., Petitioner v. Hall Data Sync Technologies LLC Patent Owner IPR2015- Patent 7,685,506 PETITION FOR INTER PARTES REVIEW

2 TABLE OF CONTENTS I. INTRODUCTION... 1 II. MANDATORY NOTICES... 1 A. Real Party-in-Interest... 1 B. The Patent Owner... 2 C. Related Matters... 2 D. Identification of Lead and Back-Up Counsel... 2 E. Service Information... 2 III. PAYMENT OF FEES... 3 IV. REQUIREMENTS FOR INTER PARTES REVIEW... 3 A. Grounds for Standing... 3 B. Statement of Precise Relief Requested (37 C.F.R (a)) and Identification of Challenges (37 C.F.R (b))... 3 C. How the Construed Claims are Unpatentable under the Statutory Grounds identified in 37 C.F.R (b)(2) and Supporting Evidence Relied upon to Support the Challenge... 4 D. Threshold Showing of Reasonable Likelihood That Petitioner Would Prevail With Respect To At Least One Challenged Claim (35 U.S.C. 314(a)) Has Been Met... 5 V. FACTUAL BACKGROUND... 5 A. Declaration Evidence... 5 B. The State of the Art as of C. The Challenged 506 Patent... 6 VI. CLAIM CONSTRUCTION (37 C.F.R (b)(3))... 8 A. Support For Claim Construction... 9 ii

3 VII. THE GROUNDS SHOWING THAT PETITIONER HAS A REASONABLE LIKELIHOOD OF PREVAILING A. Everson 094 Patent Overview B. Malpani Overview C. Element by Element Analysis Demonstrating How Everson Anticipates Claims 1-6, 8, 9, 12, 15-17, and 19 of the 506 Patent [1a] A method for synchronizing data in data fields between a plurality of first databases in communication with a second database after at least a portion of the data in any one of the plurality of first databases has been altered by addition, change, deletion or replacement of a portion thereof, the second database having a replica of data stored in the first database of the plurality of first databases, the method comprising: [1b] comparing a modification identification, wherein the modification identification includes a modification field associated with the data in one of the plurality of first databases to a modification identification associated with a prior synchronization; [1c] identifying an altered portion of the data that has the modification identification subsequent to the prior synchronization modification identification as a result of being altered; [1d] transferring only the altered portion of the data from the first database of the one of the plurality of first databases to the second database; [1e] replacing the data in the second database corresponding to the altered portion of the data; [1f] wherein transferring only the altered portion of the data further includes; iii

4 [1g] receiving a confirmation message at the one of the plurality of first databases that transferred the altered portion to the second database that the altered portion is received; and [1h] replacing the data stored in each one of the other plurality of first databases to correspond with the portion of the data altered in the one of the plurality of first databases [2a/b] The method as recited in claim 1 wherein receiving the confirmation message further comprises updating the date and time of the database synchronization [3a]. A system for synchronizing data in data fields between first and second databases after at least a portion of the data in the first database has been altered by addition, change, deletion or replacement of a portion thereof, each of the databases having a replica of data stored in the other database, the system comprising: [3b]. an input device associated with the first database for receiving data altering at least a portion of the data stored in the first database; and [3c] a central processing unit associated with the first database for comparing a modification identification associated with the data in the first database to a modification identification associated with a prior synchronization, [3d] wherein the modification identification includes a modification field associated with the data; [3e] identifying an altered portion of the data that has the modification identification subsequent to the prior synchronization modification identification as a result of being altered, [3f] transferring only the altered portion of the data from the first database to the second database, [3g] receiving a confirmation message at the first database from the second database, iv

5 [3h] and replacing the data in the second database associated with the altered portion of the data [4a/b]. The system as recited in claim 3 wherein the at least one modification identification field is automatically updated to reflect when any portion of the data is altered [5a/b] The system as recited in claim 4 wherein the modification identification field further comprises a date/time of modification field identifying a date and time of receipt of altering data [6a/b] The system as recited in claim 5 wherein the central processing unit, in identifying which portion of the data has been altered, is further operative to determine a date and time of a previous database synchronization and compare the date and time of the previous database synchronization with the date/time modification identification field associated with the data [8a/b] The system as recited in claim 5 wherein the central processing unit, in identifying which portion of the data has been altered, is further operative to determine a date and time of a previous database synchronization [9a/b] The system as recited in claim 5, wherein the central processing unit, in identifying which portion of the data has been altered is further operative to compare the date and time of the previous database synchronization with the date/time modification identification item associated with the data [12a/b] The system as recited in claim 3 wherein the central processing unit, in transferring only the altered portion of the data, is further operative to store the altered data in a redundant data database at the first database and transfer the redundant data database to the second database, and wherein, in modifying the second database, is operative to compare the altered data in the redundant data database with the replica data stored in the second database v

6 [15a/b] The system as recited in claim 3 wherein the central processing unit, upon receiving the confirmation message, is further operative to update the date and time of the database synchronization [16a/b] A method for synchronizing data in data fields between a plurality of first databases and a second database, the method comprising: providing each of the plurality of first databases with a first set of data capable of being modified in each of the first databases; [16c] providing the second database with a second set of data that corresponds to the first set of data and that is capable of being modified in the second database; [16d] altering by addition, change, deletion or replacement of a portion of the first set of data in at least one of the first databases; [16e] comparing a modification identification associated with the portion of first set of data to a modification identification associated with a prior synchronization for the first set of data, wherein the modification identification includes a modification field associated with the data; [16f] extracting the portion of the first set of data that has been altered in the one of the first databases and that has the modification identification subsequent to the prior synchronization modification identification as a result of being altered; [16g] transferring only the altered portion from the one of first databases to the second database at a predetermined time; [16h] replacing the second set of data in the second database corresponding to the altered portion of the first set of data; [16i] transferring the altered data from the second database to the other first databases; and vi

7 [16j] replacing the first set of data stored in the other first databases in accordance with the altered portion of the first set of data transferred from the second database [17a/b] A method as set forth in claim 16 wherein the step of extracting is further defined as storing the altered portion of the first set of data in a redundant database at the first database and transferring the redundant database to the second database and comparing the altered portion of the first set of data in the redundant database with the second set of data stored in the second database [19a/b] A method as set forth in claim 16 further comprising altering by addition, change, deletion or replacement of a portion of the second set of data in the second databases; [19c] extracting the portion of the second set of data that has been altered in the second database; [19d] transferring only the altered portion from the second databases to the plurality of first databases at a predetermined time; and [19e] replacing the first set of data in the plurality of first databases in accordance with the altered portion of the second set of data D. Element by Element Analysis Demonstrating How Malpani Anticipates Claims 1-6, 8, 9, 12, 13, and 15 of the 506 Patent [1a] A method for synchronizing data in data fields between a plurality of first databases in communication with a second database after at least a portion of the data in any one of the plurality of first databases has been altered by addition, change, deletion or replacement of a portion thereof, the second database having a replica of data stored in the first database of the plurality of first databases, the method comprising: [1b] comparing a modification identification, wherein the modification identification includes a modification field associated with the data in one of the plurality of first vii

8 databases to a modification identification associated with a prior synchronization; [1c] identifying an altered portion of the data that has the modification identification subsequent to the prior synchronization modification identification as a result of being altered; [1d] transferring only the altered portion of the data from the first database of the one of the plurality of first databases to the second database; [1e] replacing the data in the second database corresponding to the altered portion of the data; [1f] wherein transferring only the altered portion of the data further includes; [1g] receiving a confirmation message at the one of the plurality of first databases that transferred the altered portion to the second database that the altered portion is received; and [1h] replacing the data stored in each one of the other plurality of first databases to correspond with the portion of the data altered in the one of the plurality of first databases [2a/b] The method as recited in claim 1 wherein receiving the confirmation message further comprises updating the date and time of the database synchronization [3a]. A system for synchronizing data in data fields between first and second databases after at least a portion of the data in the first database has been altered by addition, change, deletion or replacement of a portion thereof, each of the databases having a replica of data stored in the other database, the system comprising: [3b]. an input device associated with the first database for receiving data altering at least a portion of the data stored in the first database; and viii

9 [3c] a central processing unit associated with the first database for comparing a modification identification associated with the data in the first database to a modification identification associated with a prior synchronization, [3d] wherein the modification identification includes a modification field associated with the data; [3e] identifying an altered portion of the data that has the modification identification subsequent to the prior synchronization modification identification as a result of being altered, [3f] transferring only the altered portion of the data from the first database to the second database, [3g] receiving a confirmation message at the first database from the second database, [3h] and replacing the data in the second database associated with the altered portion of the data [4a/b]. The system as recited in claim 3 wherein the at least one modification identification field is automatically updated to reflect when any portion of the data is altered [5a/b] The system as recited in claim 4 wherein the modification identification field further comprises a date/time of modification field identifying a date and time of receipt of altering data [6a/b] The system as recited in claim 5 wherein the central processing unit, in identifying which portion of the data has been altered, is further operative to determine a date and time of a previous database synchronization and compare the date and time of the previous database synchronization with the date/time modification identification field associated with the data [8a/b] The system as recited in claim 5 wherein the central processing unit, in identifying which portion of the data has ix

10 been altered, is further operative to determine a date and time of a previous database synchronization [9a/b] The system as recited in claim 5, wherein the central processing unit, in identifying which portion of the data has been altered is further operative to compare the date and time of the previous database synchronization with the date/time modification identification item associated with the data [12a/b] The system as recited in claim 3 wherein the central processing unit, in transferring only the altered portion of the data, is further operative to store the altered data in a redundant data database at the first database and transfer the redundant data database to the second database, and wherein, in modifying the second database, is operative to compare the altered data in the redundant data database with the replica data stored in the second database [13a/b] The system as recited in claim 12, wherein the central processing unit is further operative to transfer identification information identifying the first database [15a/b] The system as recited in claim 3 wherein the central processing unit, upon receiving the confirmation message, is further operative to update the date and time of the database synchronization [16a/b] A method for synchronizing data in data fields between a plurality of first databases and a second database, the method comprising: providing each of the plurality of first databases with a first set of data capable of being modified in each of the first databases; [16c] providing the second database with a second set of data that corresponds to the first set of data and that is capable of being modified in the second database; [16d] altering by addition, change, deletion or replacement of a portion of the first set of data in at least one of the first databases; x

11 [16e] comparing a modification identification associated with the portion of first set of data to a modification identification associated with a prior synchronization for the first set of data, wherein the modification identification includes a modification field associated with the data; [16f] extracting the portion of the first set of data that has been altered in the one of the first databases and that has the modification identification subsequent to the prior synchronization modification identification as a result of being altered; [16g] transferring only the altered portion from the one of first databases to the second database at a predetermined time; [16h] replacing the second set of data in the second database corresponding to the altered portion of the first set of data; [16i] transferring the altered data from the second database to the other first databases; and [16j] replacing the first set of data stored in the other first databases in accordance with the altered portion of the first set of data transferred from the second database [17a/b] A method as set forth in claim 16 wherein the step of extracting is further defined as storing the altered portion of the first set of data in a redundant database at the first database and transferring the redundant database to the second database and comparing the altered portion of the first set of data in the redundant database with the second set of data stored in the second database [19a/b] A method as set forth in claim 16 further comprising altering by addition, change, deletion or replacement of a portion of the second set of data in the second databases; [19c] extracting the portion of the second set of data that has been altered in the second database; xi

12 [19d] transferring only the altered portion from the second databases to the plurality of first databases at a predetermined time; and [19e] replacing the first set of data in the plurality of first databases in accordance with the altered portion of the second set of data VIII. CONCLUSION xii

13 I. INTRODUCTION Pursuant to the provisions of 35 U.S.C , Unified Patents Inc., ( Unified or Petitioner ) hereby petitions the Patent Trial and Appeal Board to institute inter partes review of claims 1-6, 8, 9, 12, 13, 15-17, and 19 of U.S. Patent No. 7, 685,506 to Fino et al. ( the 506 Patent, Ex. 1001). The 506 Patent is remarkable, not because it attempts to claim anything new, but because it is completely devoted to a real estate application program with only a fleeting reference to databases. It then boldly claims core database synchronization techniques database synchronization using timestamps that have been discussed and used for decades by the computer science community. The Petitioner uses two references to independently demonstrate that the challenged claims are unpatentable, but could have used more. II. MANDATORY NOTICES Pursuant to 37 C.F.R. 42.8(a)(1), Unified provides the following mandatory disclosures. A. Real Party-in-Interest Pursuant to 37 C.F.R. 42.8(b)(1), Petitioner certifies that Unified is the real party-in-interest, and further certifies that no other party exercised control or could exercise control over Unified s participation in this proceeding, the filing of this petition, or the conduct of any ensuing trial. See Ex

14 B. The Patent Owner The 506 Patent is assigned to Hall Data Sync Technologies LLC ( Hall Data Sync ). C. Related Matters The 506 Patent has been asserted in the following litigations, none of which involve Unified: 1. Hall Data Sync v. SugarSync, Inc., 2-15-cv (EDTX, filed 1/5/2015) 2. Hall Data Sync v. Dropbox, Inc., 2-15-cv (EDTX, filed 1/5/2015) 3. Hall Data Sync v. Box Inc., 2-15-cv (EDTX, filed 1/5/2015) 4. Hall Data Sync v. Google Inc., 2-15-cv (EDTX, filed 1/5/2015) 5. Hall Data Sync v. Apple Inc., 2-15-cv (EDTX, filed 1/5/2015) 6. Hall Data Sync v. Microsoft Corp., 2-15-cv (EDTX, filed 1/15/2015) D. Identification of Lead and Back-Up Counsel Pursuant to 37 C.F.R. 42.8(b)(3), Petitioner provides the following designation of counsel: Lead counsel is Michael L. Kiklis (Reg. No. 38,939) and back-up counsel are Scott A. McKeown (Reg. No. 42,866) and Katherine D. Cappaert (Reg. No. 71,639). E. Service Information Pursuant to 37 C.F.R. 42.8(b)(4), papers concerning this matter should be served on the following: 2

15 Address: Michael L. Kiklis Oblon LLP 1940 Duke Street Alexandria, VA Telephone: (703) /(703) (main) Fax: (703) III. PAYMENT OF FEES The undersigned authorizes the Office to charge the required fees as well as any additional fees that might be due to Deposit Account No IV. REQUIREMENTS FOR INTER PARTES REVIEW As set forth below and pursuant to 37 C.F.R , each requirement for inter partes review of the 506 Patent is satisfied. A. Grounds for Standing Petitioner certifies pursuant to 37 C.F.R (a) that the 506 Patent is available for inter partes review and that Petitioner is not barred or estopped from requesting inter partes review challenging the patent claims on the grounds identified herein. B. Statement of Precise Relief Requested (37 C.F.R (a)) and Identification of Challenges (37 C.F.R (b)) Petitioner requests inter partes review and cancellation of claims 1-6, 8, 9, 12, 13, 15-17, and 19 of the 506 Patent based on the following three grounds: 1. Claims 1-6, 8, 9, 12, 15-17, and 19 are anticipated under 35 U.S.C. 3

16 102(b) by U.S. Patent No. 5,261,094 ( the 094 patent ) to Everson ( Everson, Ex. 1003). 2. Claims 1-6, 8, 9, 12, 13, and 15 are anticipated under 35 U.S.C. 102(b) by Ambarish Malpani and Divyakant Agarwal, Efficient Information Dissemination in Computer Networks, Proceedings of the 14th Conference on Local Computer Networks, October 1989, Mineapolis, MN. Print ISBN: Pages ( Malpani, Ex.1002) 3. Claims 16, 17, and 19 are obvious under 35 U.S.C. 103(a) in view of Malpani as well as the knowledge of one of ordinary skill in the art. C. How the Construed Claims are Unpatentable under the Statutory Grounds identified in 37 C.F.R (b)(2) and Supporting Evidence Relied upon to Support the Challenge The challenged claims are to be construed as indicated in Section VI, below. Pursuant to 37 C.F.R (b)(4), an explanation of how the challenged claims are unpatentable under the statutory grounds identified above, including the identification of where each element of the claim is found in the prior art, is provided in Section VII, below, in the form of an analysis. Pursuant to 37 C.F.R (b)(5), the appendix numbers of the supporting evidence relied upon to support the challenges and the relevance of the evidence to the challenges raised, including identifying specific portions of the evidence that support the challenges, 4

17 are provided in Section VII, below, in the form of an analysis. D. Threshold Showing of Reasonable Likelihood That Petitioner Would Prevail With Respect To At Least One Challenged Claim (35 U.S.C. 314(a)) Has Been Met Information presented in this Petition, including the unpatentability grounds detailed in Section VII, below, establishes a reasonable likelihood that Petitioner will prevail with respect to at least one of the challenged claims. See 35 U.S.C. 314(a). Indeed, that section, supported by the Hutchinson declaration (Ex. 1006), demonstrates how the challenged claims are rendered unpatentable. V. FACTUAL BACKGROUND A. Declaration Evidence This Petition is supported by the declaration of Professor Norman Hutchinson, Ph.D. from the University of British Columbia (attached as Ex. 1006). Dr. Hutchinson offers his opinion with respect to the skill level of one of ordinary skill in the art (Ex. 1006, 19-20), the content and state of the prior art (Ex. 1006, 21-22), claim construction (Ex. 1006, 14), and the teachings and suggestions that one of ordinary skill would understand based on Exs (Ex. 1006, pp ). Dr. Hutchinson is an Associate Professor of Computer Science at the University of British Columbia. He has over twenty-five years of experience in distributed systems and has written and lectured extensively on this topic. See Ex This Petition is also supported by the declaration of Ms. Jodi Gregory who 5

18 testifies that Exs and 1004 were publicly available before February 13, See Ex B. The State of the Art as of 1995 Database technology has a long and storied history in the computer science field. As early as the 1960s, databases were a very active area in computer science research and synchronization was an issue very early on. For example, in 1975, the problem of maintaining duplicate, synchronized databases was discussed, 1 and of course, C.J.Date s seminal treatise An Introduction to Database Systems (1 st edition 1981) also discussed synchronization and various techniques for solving this problem. That is why in 1989 the publication date of Malpani and in 1991 the filing date of Everson the 506 Patent s database synchronization technique was disclosed. Dr. Hutchinson provides a more detailed overview of the state of the art in Ex. 1006, C. The Challenged 506 Patent With barely more than a column devoted to database synchronization, the 506 Patent attempts to claim database synchronization using timestamps. For 1 Johnson, Paul R. and Thomas, Robert H., The Maintenance of Duplicate Databases, Internet Request for Comments #677, January 27, Available from: 6

19 example, in a distributed database environment, the patent claims comparing modification identifiers (e.g., timestamps) to identify that data has been modified in a database and updating another database with the altered data. The database that sent the update receives a confirmation that the altered data was received, and that database propagates the update to other databases. See Ex. 1001, cl. 1. This technique is well known, and simply unpatentable. During prosecution, the applicants admitted that databases were known and altering databases was known, but argued that their method of synchronizing databases was somehow new. Ex. 1008, at 31. For example, the applicants argued that the prior art did not teach sending only the altered data in an update. Id. at 15. This argument failed, and ultimately, the applicants had to add the concept of modification identification fields and data fields to the claims to gain allowance: Ex. 1008, at 16. The Examiner found that the modification identification including a modification field associated with the data amendment was persuasive because one reference included timestamps not associated with data and the other reference only identified data modifications without timestamps. 7

20 Ex. 1008, at 6-7. Petitioner relies upon two references that each include a modification field associated with the data. VI. CLAIM CONSTRUCTION (37 C.F.R (B)(3)) Pursuant to 37 C.F.R (b)(3), the claims subject to inter partes review shall receive the broadest reasonable construction in light of the specification of the patent in which [they] appear[]. See 42 C.F.R. 100(b). If the Patent Owner contends that a claim construction different than the Broadest Reasonable Interpretation should apply to avoid prior art, the appropriate course is for the Patent Owner to seek to amend its claims. For the purposes of this petition, the Petitioner adopts the plain meaning for all claim terms. The Petitioner proposes a specific construction for several terms below: Claim Term Database (all claims) Central processing unit Proposed construction A collection of data Any computation device 8

21 (claims 3-15) Modification identification (all claims) Modification field (claims 1, 3, 4, 5, 16) Any information related to a modification Information included in the modification identification A. Support For Claim Construction Database: Webster's College New World Dictionary (Fourth Edition) defines a database as: a large collection of data in a computer, organized so that it can be expanded, updated, and retrieved rapidly for various uses and any large or extensive collection of information. Dr. Hutchinson testifies that one of ordinary skill in the art would understand that with reference to computers, a database is simply a collection of data that is stored and manipulated by a computer. The 506 Patent uses this term in its most general sense and not inconsistently with its ordinary meaning. See e.g., Ex. 1001, 8:6-7; 8:53-9:50. Dr. Hutchinson therefore concludes that one of ordinary skill in the art would understand that the broadest reasonable interpretation of this term is therefore a collection of data. Ex. 1006, 14. Central Processing Unit: This term does not appear in the specification, only the claims. Therefore, Petitioner uses its ordinary meaning as its broadest reasonable interpretation, which, as Dr. Hutchinson testifies, is any computation device, including a computer processor. Ex. 1006, 14. Modification identification: Again, this term is not found in the 9

22 specification, only the claims. Dr. Hutchinson notes that the specification describes only three fields in the table at 8:12-20 that have anything to do with modifications. Fields 1-6 are data and field 10 is a unique record identifier that is the subject of claim 10, which has nothing to do with modification identifications and modification fields in the other claims. The modification-related fields include the Last Modified, Last Modified By, and Last Modified By Site fields. Dr. Hutchinson therefore concludes that the term modification identification would be understood by one of ordinary skill in the art as referring to any or all of those fields. Dr. Hutchinson concludes that one skilled in the art would understand that the broadest reasonable interpretation of this term is any information related to a modification. Ex. 1006, 14. Modification Field: Like the term modification identification, this term also does not appear in the specification, only the claims. As mentioned above, the specification at 8:12-20 provides only three examples of fields that have anything to do with modifications. Claims 1, 3, and 16 recite that the modification identification includes a modification field associated with the data. Although claim 5 refers to modification identification field, one of ordinary skill would understand that to mean modification field when the claim limits that term to a date/time of modification field. Also, field 7 in the table at 8:12-20 includes an example of a Last Modified field, which is a time stamp. Dr. Hutchinson 10

23 therefore concludes that one of ordinary skill in the art would understand the broadest reasonable interpretation of modification field to mean information included in the modification identification and per claims 1, 3, and 16, must be associated with the data. A timestamp is an example of a modification field. Ex. 1006, 14. VII. THE GROUNDS SHOWING THAT PETITIONER HAS A REASONABLE LIKELIHOOD OF PREVAILING The following is a brief description of Everson and Malpani. Dr. Hutchinson s declaration provides a much more comprehensive overview. Ex. 1006, A. Everson 094 Patent Overview Everson discloses distributed database synchronization where a Collector node periodically requests updates from a Collectee node that then sends updates that occurred after the last time the databases were synchronized. Ex. 1001, 3: Fig. 4 provides an overview of Everson: 11

24 The Collector node first checks the current time and compares it to the time of last synchronization to determine whether a predetermined period of time has elapsed. If so, it calls the Collectee node, where that node queries its database to identify the data that has changed since the last synchronization and then sends it to the Collector node. After this synchronization, both nodes update their respective time 12

25 stamps. Ex. 1001, 3: Figs. 5 and 6 provide pseudo code that describes this process in greater detail. For example, in Fig. 5, the Collector sends a confirmation message to the Collectee indicating that the update has been received: Everson uses the LU6.2 protocol for its underlying communication mechanism, and the CONFIRMED verb is described in LU6.2 documentation available in 1992 as performing exactly this functionality. Ex. 1004, p. 37, 46, 74, Moreover, Everson s updates get propagated throughout the entire distributed database because each node can be both a Collector and a Collectee. Fig. 2 shows how these dual-purpose nodes propagate the updates throughout the entire network: 13

26 Everson explains that, for example, Node 14 is known as the Collector node because it collects data from the Collectee node 22. In turn node 14 is in the Collectee node for Collector node 10. Ex. 1003, 2: Propagation of updates throughout the nodes of the entire system must be accomplished for the system to operate properly. Ex. 1006, 30. Everson discloses the claimed modification identification and modification field associated with the data as shown in the following table from Fig. 3, known as the shadow table that contains the data to be replicated: 14

27 Each row contains (1) a key that uniquely identifies the row, (2) data (X, Y,... ), (3) an indication that a row has been deleted (DEL?) and (4) a timestamp indicating when this row was last updated (TLU). Both the DEL? field and the TLU field constitute the claimed modification identification because they are information related to a modification, and the TLU field constitutes the claimed modification field because it is a timestamp associated with the data in that row. Ex. 1006, 31; Ex. 1003, Fig. 3; 3:7-16. Everson thus discloses all the features of claims 1-6, 8, 9, 12, 15-17, and 19. At of Ex. 1006, Dr. Hutchinson provides a more detailed overview of Everson, including a discussion of the pseudo code, LU6.2, and the various database commands that Everson utilizes. B. Malpani Overview Malpani discloses synchronization between objects, which includes distributed databases. Ex. 1002, p Malpani uses a log-based database where each log stores a series of events. Each event is comparable to a row in a relational database because it holds data from the database. Each row, er, contains (1) the data itself (er.op, referring to the operation that created the data along with any parameters of the operation), (2) an indication of the node on which the data was changed (er.node), and (3) the time of the change (er.time). Both er.node and er.time constitute the claimed modification identification because they are information related to a modification, and er.time constitutes the claimed 15

28 modification field because it indicates the time the associated data was modified. Ex. 1006, 25; Ex. 1002, p The elements within the log do not change; rather new events are added to the log that supersede earlier events. In this manner, one need only look at the latest event for a given piece of data to determine that data s latest state. Dr. Hutchinson created the following diagram to explain this concept: When the latest data for key1 is needed, the log is accessed from newest to oldest, and the first match is returned. In this example, the entry at time6 is the latest. The other entries for key1 at time1 and time4 would be ignored. Each entry, known as er, contains the data and a timestamp associated with that data. Ex. 1006, 25. Each node in the system contains a log (L i ) that includes all changes anywhere within the distributed database as well as a time table (T i ) which is a two dimensional array that reflects that node s knowledge of all updates within the 16

29 system. Dr. Hutchinson created the following diagram to better illustrate this concept: Dr. Hutchinson explains: When the entry T i [k, l] equals some value t, this node knows that node k is up to date with node l up to time t. That is, node k has seen all the events that happened in node l before time t, according to node l s clock. This means that node k has most accepted updates from node l at time t. Of particular importance is the column of the time table whose second index is the index of the node itself, that is, T i [*, i]. The entry in that column at position k (when T i [k, i] equals some value t) indicates when node i has most recently sent its updates to node k. The corresponding entry in row i (when T i [i, k] equals some value t) indicates when node i has most recently received updates from node k. Whenever a propagation message is received by a node, the message contains all the log entries that the sender believes the receiver has not yet seen. These log entries will be merged into the receiver s log. The propagation message also contains a copy of the sender s time table. When a sender node i sends a message to node k 17

30 with T i [i, k] equal to some value t, this means that node i has seen every event on node k with timestamp less than or equal to t. This message is therefore a confirmation message to node k that node i has seen all the events that node k has sent to node i with timestamps less than or equal to t. Ex. 1006, Each node periodically propagates updates throughout the network. Each update includes a compressed log (L i ) which includes only those updates that the receiving node needs, based on a timestamp comparison using T i, and includes the sender s time table. Such propagation messages serve two purposes (1) to update the receiving node s database with the most recent data and (2) to inform the receiver node that the sender has received all the updates that the receiver had sent it. This second purpose is accomplished because each propagation message includes the sender s time table, thus providing the claimed confirmation message. As Dr. Hutchinson explains, [w]hen a sender node i sends a message to node k with T i [i, k] equal to some value t, this means that node i has seen every event on node k with timestamp less than or equal to t. Ex. 1006, As in all database synchronization systems, it is essential that all updates eventually get propagated system wide. Otherwise the system simply would not work properly. Ex. 1006, 28. Indeed, Malpani recognizes that [t]he need for propagation of knowledge in distributed systems is fundamental to most distributed algorithms.... Ex. 1002, p Also, because [p]ropagation of information, as 18

31 soon as it becomes known... is prohibitively expensive, sending updates periodically (lazy propagation) as in the 506 Patent and Malpani can work well, but each site eventually obtains all the information in the network. Ex. 1002, p As a result, Malpani renders the challenged claims unpatentable. C. Element by Element Analysis Demonstrating How Everson Anticipates Claims 1-6, 8, 9, 12, 15-17, and 19 of the 506 Patent The following analysis demonstrates, on a limitation-by-limitation basis, how claims 1-6, 8, 9, 12, 15-17, and 19 of the 506 Patent are anticipated by Everson (Ex. 1003) under 35 U.S.C For ease of reference, this analysis includes letters for the individual claim elements (e.g., 1a). This analysis is a presentation of Dr. Hutchinson s analysis from his claim chart in his declaration, although shortened in various places. Ex. 1006, pp Text in italics is explanatory testimony from Dr. Hutchinson s claim chart (i.e., his testimony). Id. All other text below are direct quotes from Ex [1a] A method for synchronizing data in data fields between a plurality of first databases in communication with a second database after at least a portion of the data in any one of the plurality of first databases has been altered by addition, change, deletion or replacement of a portion thereof, the second database having a replica of data stored in the first database of the plurality of first databases, the method comprising: EVERSON discloses a method for synchronizing data in data fields between a plurality of first databases in communication with a second database. EVERSON discloses a method of replicating changes made 19

32 to databases distributed throughout a computer network. The use of the term shadowing below indicates replication of data in databases. [Ex. 1006, p. 34] A method of replicating changes made to databases distributed throughout a computer network is described. A first program (TP1) in the Collector node instructs a second program (TP2) in the Collectee node to send all updates to a database since the last conversation. TP2 processes queries to retrieve any changes made since the last conversation between the Collector and Collectee nodes and send the data to TP1, which updates the copy of the database on its own system. [Ex. 1003, Abstract] Since the invention for synchronizing the databases to be described herein is the same for all network structures, the detailed description will be limited to the hierarchical structure as further shown in FIG. 2. In this example, node 22 has recently been updated with changes to its phone directory/address book. It is referred to as the Collectee node. Node 14 is known as the Collector node because it collects data from the Collectee node 22. In turn node 14 is in the Collectee node for Collector node 10. The shadowing process is always initiated by the Collector node. This ensures that no undesired data is sent to a node. The Collector node can be any node within the network. A node doesn't need to be only a Collector, it can also be a Collectee in another shadowing process, so the place the node has within the network does not matter. [Ex. 1003, 2:51-66] EVERSON discloses that data in the first database may be altered by 20

33 a number of operations, including updates and deletions. [Ex. 1006, p. 35] It is the object of this invention to provide a method for synchronizing changes to relational databases in a computing network. It is a further object of this invention to provide a method for synchronizing changes to databases in a peer to peer relationship. It is still another object of this invention to provide a method for synchronizing changes to databases in a hierarchical relationship. These objects, and others to be described, are accomplished by the following method in which the node containing the "changed" database is referred to as the "Collectee" and the database to be updated is referred to as the "Collector". Data variables that exist in databases D1 and D2 are said to be shadowed in D1 if updates occur in D2 but not D1. [Ex. 1003, 1:38-55] As updates are made on the Collectee node, each record is timestamped with the date/time of the update. If a record is deleted, a physical deletion does not occur but instead a delete indicator is turned on in the record. [Ex. 1003, 1:56-59] (emphasis added) [1b] comparing a modification identification, wherein the modification identification includes a modification field associated with the data in one of the plurality of first databases to a modification identification associated with a prior synchronization; EVERSON discloses that the data in each database has a corresponding modification identification, which includes a modification field associated with that data. The data of interest is stored in rows in the table called shadow_tbl. The key of each row 21

34 is in the column named key. The data itself can be stored in any number of columns of any types; they are referred to as the columns X, Y, in the table. This is disclosed in the description of the table below, as well as in FIG. 3. The modification identification is the combination of the del? and TLU (time last updated) fields of each row of the database, and the modification field of each row of data is the TLU field. [Ex. 1006, 14, 30-35; Ex. 1006, p. 36] Referring to FIG. 3, the control table (shadow-- tbl) 60 for the database to be shadowed in the Collector node is illustrated. Shadow-- tbl 60 contains several data entries as follows: key=identifier which uniquely identifies each row of unit data XY... =represents columns in the data table del? =logical indicator that record has been deleted TLU=time last updated. (Time stamp when this row was last updated). [Ex. 1003, 3:7-16] [Ex. 1003, FIG. 3] EVERSON teaches a synchronization method that compares the modification identification associated with the first database to a modification identification associated with a prior synchronization. EVERSON discloses that each time a data record is modified, the 22

35 timestamp of the change is recorded along with the record. [Ex. 1006, p. 37] As updates are made on the Collectee node, each record is timestamped with the date/time of the update. If a record is deleted, a physical deletion does not occur but instead a delete indicator is turned on in the record. [Ex. 1003, 1:56-59] The modification identification associated with a prior synchronization is stored in the shadow control table as the field TLS (for the Collectee to Collector direction) and TLC (for the Collector to Collectee direction). [Ex. 1006, 30-35; Ex. 1006, p. 37] Also shown in FIG. 3 is the shadow control table 62 (Collectee-- tbl) which is contained in the Collectee node. This table contains the following data: TLC=time last called. (A time stamp of the last time a successful conversation was completed normally with TP2). DTC=delta time between collections (amount of time between collection calls to this node.) TLS=time last serviced. (A time stamp of the last time a successful conversation was completed with TP1. Updated by TP2). [Ex. 1003, 3:17-32] The pseudo code for the COLLECTEE in Fig. 6 shows that the COLLECTEE compares the modification identification (including the TLU from the Shadow_Tbl) of each data element with the modification identification associated with a prior synchronization (TLS from the COLLECTEE_TBL). See 30. The highlighted where 23

36 clause below compares the TLU field of each row to TLS which is the time of the prior synchronization. [Ex. 1006, p. 38] [Ex. 1003, FIG.6, lines 2 and 3](emphasis added) [1c] identifying an altered portion of the data that has the modification identification subsequent to the prior synchronization modification identification as a result of being altered; EVERSON identifies an altered portion of the data that has a modification identification subsequent to the prior synchronization modification identification as a result of being altered. EVERSON uses the database cursor QUERY to refer to the collection of data that has the modification identification subsequent to the prior synchronization modification identification. The result set that QUERY is a cursor over is the altered portion of the data. [Ex. 1006, 14, 30-35; Ex. 1006,pp. 38] [Ex. 1003, FIG.6, lines 2 and 3](emphasis added) 24

37 [1d] transferring only the altered portion of the data from the first database of the one of the plurality of first databases to the second database; EVERSON transfers only the altered portion of the data from the first database to the second database. Each element from the result set that QUERY is a cursor over is fetched and sent to the second database using the LU6.2 communication verb SEND_DATA. [Ex. 1006, 30-35; Ex. 1006, p. 39] [Ex. 1003, FIG. 6, lines 10-14](emphasis added) [1e] replacing the data in the second database corresponding to the altered portion of the data; EVERSON replaces the data in the second database corresponding to the altered portion of the data. EVERSON discloses that the Collector receives the data from the Collectee and updates the Shadow_tbl. [Ex. 1006, 30-35; Ex p. 39] 25

38 [Ex. 1003, FIG. 5, lines 20-31](emphasis added) [1f] wherein transferring only the altered portion of the data further includes; See claim element [1d]. [1g] receiving a confirmation message at the one of the plurality of first databases that transferred the altered portion to the second database that the altered portion is received; and EVERSON discloses that the first database receives a confirmation message that the second database received the altered portion of the data. EVERSON uses the LU6.2 communication protocol. [Ex. 1006, 35; Ex p. 40] While these examples employ the LU6.2 communications protocol, it is readily apparent that any suitable peer-to-peer communications protocol can be used. [Ex. 1003, 1:62-66] In the LU6.2 communications protocol, the CONFIRMED verb sends a confirmation reply to the remote process. This is seen on line 36 of the Collector Pseudocode in Fig. 5 and is the confirmation message sent from the Collector to the Collectee indicating confirmation. [Ex. 1006, 30-35; Ex p. 40] [Ex. 1003, FIG. 5, lines 32-39](emphasis added) One of ordinary skill in the art would recognize that the CONFIRMED LU6.2 verb means that the claimed confirmation 26

39 message is necessarily present because that is the functionality of this verb. See for example: Ex. 1004, p. 37, 46, 74, [Ex. 1006, p. 40] [1h] replacing the data stored in each one of the other plurality of first databases to correspond with the portion of the data altered in the one of the plurality of first databases. EVERSON replaces the data in the second database corresponding to the altered portion of the data. [Ex. 1006, p. 40] See claim element [1e]. EVERSON also replaces the data stored in all of the other databases that are connected to the Collector and the Collectee. Everson shows that a single node can be both a Collector and a Collectee, so information would be sent both up and down the hierarchy of databases shown in FIG. 2. Even if this functionality were not explicit, it must be performed to ensure the correct operation of the distributed system, and thus is necessarily present. [Ex. 1006, 30-35; Ex. 1006, pp ] Since the invention for synchronizing the databases to be described herein is the same for all network structures, the 27

40 detailed description will be limited to the hierarchical structure as further shown in FIG. 2. In this example, node 22 has recently been updated with changes to its phone directory/address book. It is referred to as the Collectee node. Node 14 is known as the Collector node because it collects data from the Collectee node 22. In turn node 14 is in the Collectee node for Collector node 10. The shadowing process is always initiated by the Collector node. This ensures that no undesired data is sent to a node. The Collector node can be any node within the network. A node doesn't need to be only a Collector, it can also be a Collectee in another shadowing process, so the place the node has within the network does not matter. [Ex. 1003, 2:51-66](emphasis added) ; see also, Abstract; 1:8-12. The problem in such a distributed environment, however, is one of ensuring that any changes made to one database are propagated to other databases in the system so that data remains consistent... These objects... are accomplished.... Ex. 1003, 1:26-35;1: [2a/b] The method as recited in claim 1 wherein receiving the confirmation message further comprises updating the date and time of the database synchronization. See claim element [1a], [1g]. EVERSON discloses that the date and time of the database synchronization is stored in the TLS field of the COLLECTEE table. It is updated each time a confirmation message is received. The confirmation message is sent by the Collector when it has received all of the data using the CONFIRMED verb at line 36 of FIG. 5. After this message has been received and the conversation is closed using 28

41 the DEALLOCATE verb at line 15 of FIG. 6, the Collectee uses the UPDATE operator to update the Collectee table and the COMMIT operator to make the changes permanent at lines 16 and 17 of FIG. 6. [Ex. 1006, p. 42] [Ex. 1003, FIG. 6, lines 14-17](emphasis added); [Ex. 1006, 30-35] [3a]. A system for synchronizing data in data fields between first and second databases after at least a portion of the data in the first database has been altered by addition, change, deletion or replacement of a portion thereof, each of the databases having a replica of data stored in the other database, the system comprising: See claim element [1a]. [3b]. an input device associated with the first database for receiving data altering at least a portion of the data stored in the first database; and EVERSON discloses that the first database is on a client computer that is capable of making alterations to at least a portion of the data stored in the first database. An input device is necessarily present in such systems. [Ex. 1006, p. 43] As updates are made on the Collectee node, each record is timestamped with the date/time of the update. If a record is deleted, a physical deletion does not occur but instead a delete indicator is turned on in the record. [Ex. 1003, 1:56-59]; see also [1a]. [3c] a central processing unit associated with the first database for comparing a modification identification associated with the data in the first database to a modification identification associated with a prior 29

42 synchronization, One of ordinary skill would understand that a processor is necessarily present in these systems. [Ex. 1006, 14; Ex. 1006, p. 43]; See claim element [1b]. [3d] wherein the modification identification includes a modification field associated with the data; See claim element [1b]. [3e] identifying an altered portion of the data that has the modification identification subsequent to the prior synchronization modification identification as a result of being altered, See claim element [1c]. [3f] transferring only the altered portion of the data from the first database to the second database, See claim element [1d]. [3g] receiving a confirmation message at the first database from the second database, See claim element [1g]. [3h] and replacing the data in the second database associated with the altered portion of the data. See claim element [1e]. [4a/b]. The system as recited in claim 3 wherein the at least one modification identification field is automatically updated to reflect when any portion of the data is altered. See claim element [3a]. EVERSON discloses that the at least one modification identification field (called the time of an event) is automatically updated to reflect whenever any portion of the data is altered. [Ex. 1006, p. 45] 30

43 See claim element [1b], [2b]. As updates are made on the Collectee node, each record is timestamped with the date/time of the update. If a record is deleted, a physical deletion does not occur but instead a delete indicator is turned on in the record. [Ex. 1003, 1:56-59] [5a/b] The system as recited in claim 4 wherein the modification identification field further comprises a date/time of modification field identifying a date and time of receipt of altering data. See claim element [4a], [1b]. The following quote shows that the modification identification field comprises the date/time of the update. [Ex. 1006, p. 45] As updates are made on the Collectee node, each record is timestamped with the date/time of the update. If a record is deleted, a physical deletion does not occur but instead a delete indicator is turned on in the record. [Ex. 1003, 1:56-59] [6a/b] The system as recited in claim 5 wherein the central processing unit, in identifying which portion of the data has been altered, is further operative to determine a date and time of a previous database synchronization and compare the date and time of the previous database synchronization with the date/time modification identification field associated with the data. See claim elements [5a], [1b], [1c]. [8a/b] The system as recited in claim 5 wherein the central processing unit, in identifying which portion of the data has been altered, is further operative to determine a date and time of a previous database synchronization. See claim elements [5a], [1b], [1c]. [9a/b] The system as recited in claim 5, wherein the central processing unit, in identifying which portion of the data has been altered is further operative to compare the date and time of the previous database 31

44 synchronization with the date/time modification identification item associated with the data. See claim elements [5a], [1b], [1c]. [12a/b] The system as recited in claim 3 wherein the central processing unit, in transferring only the altered portion of the data, is further operative to store the altered data in a redundant data database at the first database and transfer the redundant data database to the second database, and wherein, in modifying the second database, is operative to compare the altered data in the redundant data database with the replica data stored in the second database. See claim element [3a]. EVERSON discloses that the central processing unit, in transferring only the altered portion of the data, is further operative to store the altered data in a redundant data database at the first database and transfer the redundant data database to the second database, and wherein, in modifying the second database, is operative to compare the altered data in the redundant data database with the replica data stored in the second database. The altered portion of the data is stored in a redundant data database. The redundant data database is the result set selected by the SELECT operator on line 3 of FIG. 6., which is read using the cursor QUERY and which is prepared at the first database and transferred to the second database. [Ex. 1006, 30-32; Ex. 1006, pp. 47] See claim element [1c]. 32

45 [Ex. 1003, FIG.6, lines 2 and 3](emphasis added) When received by the second database, the code at lines of FIG. 5 is executed by the second database (the Collector). It compares the altered data in the redundant database which it has received using the verb RECEIVE_AND_WAIT with the replica data stored in the second database. [Ex. 1003, p. 47] [Ex. 1003, FIG. 5, lines 20-31](emphasis added) [15a/b] The system as recited in claim 3 wherein the central processing unit, upon receiving the confirmation message, is further operative to update the date and time of the database synchronization. See claim elements [3a], [1g], [2b]. [16a/b] A method for synchronizing data in data fields between a plurality of first databases and a second database, the method comprising: providing each of the plurality of first databases with a first set of data capable of being modified in each of the first databases; See claim elements [1a], [1b]. [16c] providing the second database with a second set of data that corresponds to the first set of data and that is capable of being modified in the second database; EVERSON discloses that any node can be a Collector, a Collectee, or both so that the second database has a copy of the data that it can modify, just like the first databases do. [Ex. 1006, p. 49] 33

46 See claim elements [1a], [1b]. [16d] altering by addition, change, deletion or replacement of a portion of the first set of data in at least one of the first databases; See claim element [1a]. [16e] comparing a modification identification associated with the portion of first set of data to a modification identification associated with a prior synchronization for the first set of data, wherein the modification identification includes a modification field associated with the data; See claim elements [1b], [1c]. [16f] extracting the portion of the first set of data that has been altered in the one of the first databases and that has the modification identification subsequent to the prior synchronization modification identification as a result of being altered; The select operator extracts into a result set the set of data that has been altered. [Ex. 1006, p. 49] [Ex. 1003, FIG.6, lines 2 and 3](emphasis added) See claim element [1c]. [16g] transferring only the altered portion from the one of first databases to the second database at a predetermined time; EVERSON discloses that each Collector will communicate with each Collectee when a predetermined amount of time has elapsed. The amount of time between successive synchronizations between each pair of nodes is stored in the delta time (DTC) field of the Collectee_tbl. [Ex. 1006, ;Ex. 1006, p. 50] 34

47 See claim element [1d]. Also shown in FIG. 3 is the shadow control table 62 (Collectee-- tbl) which is contained in the Collectee node. This table contains the following data: TLC=time last called. (A time stamp of the last time a successful conversation was completed normally with TP2). DTC=delta time between collections (amount of time between collection calls to this node.) TLS=time last serviced. (A time stamp of the last time a successful conversation was completed with TP1. Updated by TP2). [Ex. 1003, 3:17-32] Ex. 1003, Fig. 4. [16h] replacing the second set of data in the second database corresponding to the altered portion of the first set of data; See claim element [1e]. [16i] transferring the altered data from the second database to the other first databases; and Everson discloses that each node containing a database can play the role of both the Collector and the Collectee, so information can be sent both up and down the hierarchy of databases shown in FIG. 2. The process is exactly the same whether the transfer is up or down in the hierarchy, so the altered data will be transferred from the second database to the other first databases in exactly the same way as it is 35

48 transferred from the first database to the second database. [Ex. 1006, 30-35; Ex. 1006, p. 51] See claim element [1h]. [16j] replacing the first set of data stored in the other first databases in accordance with the altered portion of the first set of data transferred from the second database. See claim element [1h]. [17a/b] A method as set forth in claim 16 wherein the step of extracting is further defined as storing the altered portion of the first set of data in a redundant database at the first database and transferring the redundant database to the second database and comparing the altered portion of the first set of data in the redundant database with the second set of data stored in the second database. The redundant database is the result set from the select statement on line 3 of FIG. 6. The redundant database is transferred one row at a time. [Ex. 1006, p. 52] See claim elements [16a], [1d], [12b]. [19a/b] A method as set forth in claim 16 further comprising altering by addition, change, deletion or replacement of a portion of the second set of data in the second databases; See claim element [16a]. EVERSON discloses that any node can be a Collector, a Collectee, or both so that the second database has a copy of the data that it can modify, just like the first databases do. Therefore changes made in a portion of the second set of data in the second databases will be extracted, transferred, and replaced in the first databases in exactly the same way previously discussed so long as the Collector/Collectee relationships are properly configured in the control table. [Ex. 1006, 36

49 p. 53] See claim element [1a]. [19c] extracting the portion of the second set of data that has been altered in the second database; See claim elements [16f], [1b], [1c]. [19d] transferring only the altered portion from the second databases to the plurality of first databases at a predetermined time; and EVERSON discloses that each Collector will communicate with each Collectee when a predetermined amount of time has elapsed. The amount of time between successive synchronizations between each pair of nodes is stored in the delta time (DTC) field of the Collectee_tbl. [Ex. 1006, 30-35; Ex. 1006, p. 53]. See claim element [1d], [16g]. Also shown in FIG. 3 is the shadow control table 62 (Collectee-- tbl) which is contained in the Collectee node. This table contains the following data: TLC=time last called. (A time stamp of the last time a successful conversation was completed normally with TP2). DTC=delta time between collections (amount of time between collection calls to this node.) TLS=time last serviced. (A time stamp of the last time a successful conversation was completed with TP1. Updated by TP2). [Ex. 1003, 3:17-32] See also Fig. 4. [19e] replacing the first set of data in the plurality of first databases in accordance with the altered portion of the second set of data. EVERSON discloses that any node can be a Collector, a Collectee, or 37

50 both so that the second database has a copy of the data that it can modify, just like the first databases do. Therefore changes made in a portion of the second set of data in the second databases will be extracted, transferred, and replaced in the first databases in exactly the same way previously discussed so long as the Collector/Collectee relationships are properly configured in the control table. [Ex. 1006, p. 54] See claim elements [1e], [19b]. D. Element by Element Analysis Demonstrating How Malpani Anticipates Claims 1-6, 8, 9, 12, 13, and 15 of the 506 Patent The following analysis demonstrates, on a limitation-by-limitation basis, how claims 1-6, 8, 9, 12, 13, and 15 of the 506 Patent are anticipated by Malpani (Ex. 1002) under 35 U.S.C For ease of reference, this analysis includes letters for the individual claim elements (e.g., 1a). This analysis is a presentation of Dr. Hutchinson s analysis from his claim chart in his declaration, although shortened in various places. Ex. 1006, pp Text in italics is explanatory testimony from Dr. Hutchinson s claim chart (i.e., his testimony). Id. All other text below are direct quotes from Ex [1a] A method for synchronizing data in data fields between a plurality of first databases in communication with a second database after at least a portion of the data in any one of the plurality of first databases has been altered by addition, change, deletion or replacement of a portion thereof, the second database having a replica of data stored in the first database of the plurality of first databases, the method comprising: MALPANI discloses a method for synchronizing data in data fields 38

51 between a plurality of first databases in communication with a second database. MALPANI discloses a technique to manage multiple copies of replicated objects, for example, in a database, keeping them consistent when changes are made. [Ex. 1006, p. 55] The need for propagation of knowledge in distributed systems is fundamental to most distributed algorithms [17, 3, 9, 13, 11, 5]. In many of these algorithms, the information that needs to be disseminated is required to manage replicated objects, eg., name server tables, routing tables, distributed databases, etc. These objects are replicated primarily to provide fault tolerant and highly available network operations. Most applications involving replicated objects require that all copies of an object be mutually consistent. However, the degree of mutual consistency required may vary depending on the application. Fortunately in many applications pertaining to network management, lazy efforts to update all copies of a replicated object are sufficient. Furthermore, these operations do not require that update information be directly transmitted to all affected sites in a network. Often, update information or the update log can be spread in the form of gossip [13] or epidemic [5] in the network. The latter class of replica synchronization protocols are generally termed as the log propagation protocols where logs contain the accumulated update information [17]. [Ex. 1002, p. 202] MALPANI discloses that data in the first database may be altered by a number of operations including insert and delete. [Ex. 1006, p. 55] 39

52 In our model, we classify operations into two types. The first type consists of application specific operations. For example, a dictionary application will permit operations such as insert, delete, and lookup operations. [Ex. 1002, pp. 204] [1b] comparing a modification identification, wherein the modification identification includes a modification field associated with the data in one of the plurality of first databases to a modification identification associated with a prior synchronization; MALPANI discloses that the data in each database has a corresponding modification identification, which includes a modification field associated with that data. The modification identification of each object is the node and time fields of the most recent event that modified that object. The node field records the machine at which the event occurred and the time field records the logical time of occurrence of the event. The modification field is the time field, the logical time of occurrence of the most recent event that modified the object. [Ex. 1006, 14, 24-29; Ex. 1006, p. 56] Every site maintains a log that records the application specific events that have occurred in the system. The log at a site is its knowledge of these events in the system. Thus, each log is a set of events. We associate with each event in the log, the record (op, node, time) of that event, where: 1. op is the operation itself (including any parameters). 2. node is the node at which the event occurred. 3. time is the logical time of occurrence of the event. We refer to the record of an event e in the log as er. The node and the 40

53 time of occurrence of an event e are referred to by er.node and er.time respectively. [Ex. 1002, p. 204] MALPANI teaches a synchronization method that compares the modification identification associated with the first database to a modification identification associated with a prior synchronization. The modification identification associated with a prior synchronization of a node i with a node k is in the time table associated with node i (T i ) at position k, i; that is T i [k, i]. The HasReceived function compares that timestamp with the timestamp of each event to determine if the event occurred subsequent to the prior synchronization. The HasReceived function is used by the SendTo procedure. [Ex. 1006, 24-29; Ex. 1006, pp ] This algorithm is based on the simple idea that if a site N i knows that another site N j knows about event e then there is no need for N i to include e in any of its future log propagation messages destined to N i. In order to incorporate a site s knowledge about other sites knowledge a two dimensional time table, T i, of local clocks of each site is maintained. The algorithm maintains each site s time table T i such that it satisfies the time table property. The time table property requires that when T i [ k, l ] = τ, N i can assume that N k has heard of at least all those events that have occurred at N l up to N l s local time τ. This property allows a site to send only a portion of its log and still maintain the log property. The function illustrated in Figure 1 evaluates the predicate HasReceived by using the time table property. If the predicate is true 41

54 then N i is certain that N k already knows about event e. [Ex. 1002, pp ] The HasReceived function compares the modification identification of an event with the modification identification of the prior synchronization. [Ex. 1006, p. 57] [Ex. 1002, pp. 206](emphasis added) [1c] identifying an altered portion of the data that has the modification identification subsequent to the prior synchronization modification identification as a result of being altered; MALPANI identifies an altered portion of the data that has a modification identification subsequent to the prior synchronization modification identification as a result of being altered. MALPANI refers to the complete set of data in a database N i as L i, and the altered portion of the data as the compressed log L i. [Ex. 1006, 24-29; Ex. 1006, p. 58] The two communication procedures correspond to the sending and the receipt of propagation messages. In order to send a propagation message to N k, N i first discards all those events from L i that are already known to N k. The resulting compressed log L i and T i are transmitted to N k. [Ex. 1002, pp. 205] MALPANI discloses that the procedure SendTo is used to identify the altered portion of the data that has the modification indication 42

55 subsequent to the prior synchronization modification identification as a result of being altered. First the altered portion of the data L i is identified, and then it is sent to the other node (N k ). [Ex. 1006, p. 58] [Ex. 1002, p. 206] [1d] transferring only the altered portion of the data from the first database of the one of the plurality of first databases to the second database; MALPANI transfers only the altered portion of the data from the first database to the second database. [Ex. 1006, 24-29; Ex. 1006, p. 58] The two communication procedures correspond to the sending and the receipt of propagation messages. In order to send a propagation message to N k, N i first discards all those events from L i that are already known to N k. The resulting compressed log L i and T i are transmitted to N k. [Ex. 1002, pp. 205] MALPANI discloses that the procedure SendTo is used to transfer the altered portion of the data from the first database of one of the plurality of first database to the second database. In this case, the first database is N i and the second database is N k. As described in 27 above, the HasReceived function determines if the destination node k has already seen an event from node i's log L i. Each event that hasn t already been seen by node k is included in the compressed log L i, which, along with the time table, is then sent to node k. [Ex. 1006, p. 59] 43

56 [Ex. 1002, p. 206] [1e] replacing the data in the second database corresponding to the altered portion of the data; MALPANI replaces the data in the second database corresponding to the altered portion of the data. MALPANI refers to the data in a database as L i, and data appended to L i replaces data earlier in the log. [Ex. 1006, 24-29; Ex. 1006, p. 59] When N i receives a propagation message, the events in the message are appended to L i. The entries in T i are updated by using T k such that they reflect the current knowledge of N i after receiving the propagation message. [Ex. 1002, pp ](emphasis added) [1f] wherein transferring only the altered portion of the data further includes; See claim element [1d]. [1g] receiving a confirmation message at the one of the plurality of first databases that transferred the altered portion to the second database that the altered portion is received; and MALPANI discloses that the first database receives a confirmation 44

57 message that the second database received the altered portion of the data. After database N j receives a propagation message from a database N i, each message that database N j sends to N i will confirm that it has received the altered portion of the data which N i previously sent to it. Each node regularly sends propagation messages to each other node. [Ex. 1006, 24-29; Ex. 1006, p. 60] The only assumption that is made about the underlying communication network is that every site in the network has the capability to send a message to any other site in the network when there are no failures. [Ex. 1002, p. 203] The other type corresponds to the communication operations employed for propagation in the system. Such operations will generally comprise of the sending and the receipt of propagation messages. [Ex. 1002, p. 204] MALPANI incorporates the timestamps in the messages that it receives into its timetable T i. Each message that it sends includes T i, so when the first database receives a message from the second database, that message confirms that the second database has received the altered portion of the first database. The time table entry at position T i [k, i], which records what information node k has received from node i, will be updated when this confirmation message is received. [Ex. 1006, 24-29; Ex. 1006, p. 60] When N i receives a propagation message, the events in the message are appended to L i. The entries in T i are updated by using T k such that they reflect the current knowledge of N i after receiving the 45

58 propagation message. [Ex. 1002, pp ](emphasis added) [1h] replacing the data stored in each one of the other plurality of first databases to correspond with the portion of the data altered in the one of the plurality of first databases. See claim element [1e]. MALPANI also replaces the data stored in each one of the other plurality of first databases. Each time a database N i sends a propagation message to a database N k, it includes all the updates that it has received that database N k has not received. Therefore, the next time the second database sends a propagation message to any of the other plurality of first databases, the second database will send to that one of the plurality of first databases all the updates that it previously received from any of the plurality of first databases. This is the essence of the gossip or epidemic communication model of MALPANI. [Ex. 1006, 24-29; Ex. 1006, p. 61] The need for propagation of knowledge in distributed systems is fundamental to most distributed algorithms [17, 3, 9, 13, 11, 5]. In many of these algorithms, the information that needs to be disseminated is required to manage replicated objects, eg., name server tables, routing tables, distributed databases, etc. These objects are replicated primarily to provide fault tolerant and highly available 46

59 network operations. Most applications involving replicated objects require that all copies of an object be mutually consistent. However, the degree of mutual consistency required may vary depending on the application. Fortunately in many applications pertaining to network management, lazy efforts to update all copies of a replicated object are sufficient. Furthermore, these operations do not require that update information be directly transmitted to all affected sites in a network. Often, update information or the update log can be spread in the form of gossip [13] or epidemic [5] in the network. The latter class of replica synchronization protocols are generally termed as the log propagation protocols where logs contain the accumulated update information [17]. [Ex. 1002, p. 202] One of the major issues in Network Management is the efficient dissemination of information in a computer network. Propagation of information, as soon as it becomes known, via direct messages, is prohibitively expensive even in relatively small networks. Fortunately, in many applications, one can use lazy propagation of information, where each site eventually obtains all the information in the network. A common method for spreading information is by exchanging information logs amongst sites in the network. [Ex , p. 202] (emphasis added) [2a/b] The method as recited in claim 1 wherein receiving the confirmation message further comprises updating the date and time of the database synchronization. See claim elements [1a], [1g]. 47

60 MALPANI discloses that the date and time of the database synchronization is stored in the time table T i, and T i is updated each time a confirmation message is received. [Ex. 1006, 24-29; Ex. 1006, p. 62] When N i receives a propagation message, the events in the message are appended to L i. The entries in T i are updated by using T k such that they reflect the current knowledge of N i after receiving the propagation message. 48 [Ex. 1002, pp ] [3a]. A system for synchronizing data in data fields between first and second databases after at least a portion of the data in the first database has been altered by addition, change, deletion or replacement of a portion thereof, each of the databases having a replica of data stored in the other database, the system comprising: See claim element [1a]. [3b]. an input device associated with the first database for receiving data altering at least a portion of the data stored in the first database; and MALPANI discloses that the first database is on a client computer that is capable of making alterations to at least a portion of the data stored in the first database. An input device is necessarily present in these systems. [Ex. 1006, pp ] An event model of execution is used, i.e., we consider an execution in

61 our system to be composed of events and a partial order on these events [12]. Each event is associated with the site at which it occurs and a local time of occurrence. In our model, we classify operations into two types. The first type consists of application specific operations. For example, a dictionary application will permit operations such as insert, delete, and lookup operations. [Ex. 1002, pp. 204]; see also claim element [1a]. [3c] a central processing unit associated with the first database for comparing a modification identification associated with the data in the first database to a modification identification associated with a prior synchronization, One of ordinary skill would understand that a processor is necessarily present in these systems. [Ex. 1006, 14; Ex. 1006, p. 64] See claim element [1b]. [3d] wherein the modification identification includes a modification field associated with the data; See claim element [1b]. Every site maintains a log that records the application specific events that have occurred in the system. The log at a site is its knowledge of these events in the system. Thus, each log is a set of events. We associate with each event in the log, the record (op, node, time) of that event, where: 1. op is the operation itself (including any parameters). 2. node is the node at which the event occurred. 3. time is the logical time of occurrence of the event. We refer to the record of an event e in the log as er. The node and the 49

62 time of occurrence of an event e are referred to by er.node and er.time respectively. [Ex. 1002, p. 204] [3e] identifying an altered portion of the data that has the modification identification subsequent to the prior synchronization modification identification as a result of being altered, See claim element [1c]. [3f] transferring only the altered portion of the data from the first database to the second database, See claim element [1d]. [3g] receiving a confirmation message at the first database from the second database, See claim element [1g]. [3h] and replacing the data in the second database associated with the altered portion of the data. See claim element [1e]. [4a/b]. The system as recited in claim 3 wherein the at least one modification identification field is automatically updated to reflect when any portion of the data is altered. See claim element [3a]. MALPANI discloses that the at least one modification identification field (called the time of an event) is automatically updated to reflect whenever any portion of the data is altered. [Ex. 1006, p. 65] See claim element [1b], [2b]. Every site maintains a log that records the application specific events that have occurred in the system. The log at a site is its knowledge of these events in the system. Thus, each log is a set of events. We associate with each event in the log, the record (op, node, time) of that 50

63 event, where: 1. op is the operation itself (including any parameters). 2. node is the node at which the event occurred. 3. time is the logical time of occurrence of the event. We refer to the record of an event e in the log as er. The node and the time of occurrence of an event e are referred to by er.node and er.time respectively. [Ex. 1002, p. 204] [5a/b] The system as recited in claim 4 wherein the modification identification field further comprises a date/time of modification field identifying a date and time of receipt of altering data. See claim elements [4a], [1b]. The following quote shows that the modification identification field comprises the date/time of the update. [Ex. 1006, p. 66] An event model of execution is used, i.e., we consider an execution in our system to be composed of events and a partial order on these events [12]. Each event is associated with the site at which it occurs and a local time of occurrence. In our model, we classify operations into two types. The first type consists of application specific operations. For example, a dictionary application will permit operations such as insert, delete, and lookup operations. [Ex. 1002, pp. 204](emphasis added) [6a/b] The system as recited in claim 5 wherein the central processing unit, in identifying which portion of the data has been altered, is further operative to determine a date and time of a previous database synchronization and compare the date and time of the previous database synchronization with the date/time modification identification field associated with the data. See claim elements [5a], [1b], [1c]. 51

64 [8a/b] The system as recited in claim 5 wherein the central processing unit, in identifying which portion of the data has been altered, is further operative to determine a date and time of a previous database synchronization. See claim elements [5a], [1b], [1c]. [9a/b] The system as recited in claim 5, wherein the central processing unit, in identifying which portion of the data has been altered is further operative to compare the date and time of the previous database synchronization with the date/time modification identification item associated with the data. See claim elements [5a], [1b], [1c]. [12a/b] The system as recited in claim 3 wherein the central processing unit, in transferring only the altered portion of the data, is further operative to store the altered data in a redundant data database at the first database and transfer the redundant data database to the second database, and wherein, in modifying the second database, is operative to compare the altered data in the redundant data database with the replica data stored in the second database. See claim element [3a]. MALPANI discloses that the central processing unit, in transferring only the altered portion of the data, is further operative to store the altered data in a redundant data database at the first database and transfer the redundant data database to the second database, and wherein, in modifying the second database, is operative to compare the altered data in the redundant data database with the replica data stored in the second database. The redundant data database is the compressed log L i, which is prepared on the first database and transferred to the second database. [Ex. 1006, p. 68] See claim element [1c]. 52

65 When received by the second database, the procedure ReceiveFrom is executed by the second database. It compares the altered data in the redundant database (the compressed log) with the replica data stored in the second database. [Ex. 1006, p. 68] [Ex. 1002, pp ]; See claim element [1e]. [13a/b] The system as recited in claim 12, wherein the central processing unit is further operative to transfer identification information identifying the first database. The procedure ReceiveFrom is parameterized by the identification information identifying the first database, the SiteId k, which is the first database that transferred this information to the second database. [Ex. 1006, p. 69] [Ex. 1002, pp. 206] [15a/b] The system as recited in claim 3 wherein the central processing unit, upon receiving the confirmation message, is further operative to update the date and time of the database synchronization. 53

66 See claim elements [3a], [1g], [2b]. A. Element by Element Analysis Demonstrating How Claims 16, 17, and 19 of the 506 Patent Are Obvious in View of Malpani The following analysis demonstrates, on a limitation-by-limitation basis, how claims 16, 17, and 19 of the 506 Patent are obvious under 35 U.S.C. 103(a) in view of Malpani and the knowledge of one of ordinary skill in the art. For ease of reference, this analysis includes letters for the individual claim elements (e.g., 1a). This analysis is a presentation of Dr. Hutchinson s analysis from his claim chart in his declaration, although shortened in various places. Ex. 1006, pp Text in italics is explanatory testimony from Dr. Hutchinson s claim chart (i.e., his testimony). Id. All other text below are direct quotes from Ex For claims 16, 17, and 19, I analyze these claims under an obviousness analysis because these claims require that the database updates are transferred at a predetermined time. The Malpani reference is not explicit about this triggering event, which suggests to one of ordinary skill in the art that this trigger can be accomplished using any available technique. The most likely techniques to be used are (1) performing the transfer after a predetermined number of updates have occurred or (2) after a predetermined amount of time has elapsed (see e.g., Ex. 1003, 3:17-32; Fig. 4). One of ordinary skill will therefore appreciate that there is a very limited universe of options for such triggering events, leading one of ordinary skill in the art to conclude that either of such triggering events would be suitable 54

67 based upon various environmental or design considerations. The selection of one of these triggering events is an obvious matter of design choice. [Ex. 2006, p. 70] [16a/b] A method for synchronizing data in data fields between a plurality of first databases and a second database, the method comprising: providing each of the plurality of first databases with a first set of data capable of being modified in each of the first databases; See claim elements [1a], [1b]. [16c] providing the second database with a second set of data that corresponds to the first set of data and that is capable of being modified in the second database; MALPANI discloses that all databases are treated equivalently, so the second database has a copy of the data which it can modify, just like the first databases do. [Ex. 1006, p. 71] See claim elements [1a], [1b]. [16d] altering by addition, change, deletion or replacement of a portion of the first set of data in at least one of the first databases; See claim element [1a]. [16e] comparing a modification identification associated with the portion of first set of data to a modification identification associated with a prior synchronization for the first set of data, wherein the modification identification includes a modification field associated with the data; See claim elements [1b], [1c]. [16f] extracting the portion of the first set of data that has been altered in the one of the first databases and that has the modification identification subsequent to the prior synchronization modification identification as a result of being altered; The portion of the first set of data that has been altered in the one of the first databases and that has the modification identification 55

68 subsequent to the prior synchronization modification identification as a result of being altered is the compressed log L i. The SendTo procedure first extracts this data into the compressed log, and subsequently sends it to N k. [Ex. 1006, p. 72] See claim element [1c]. [Ex. 1002, p. 206] [16g] transferring only the altered portion from the one of first databases to the second database at a predetermined time; MALPANI is completely general to when the propagation messages are sent as MALPANI uses a gossip or epidemic style of communication. Messages can be sent at a predetermined time or via some other mechanism, as one of ordinary skill would understand. As discussed above in 38, it would be an obvious matter of design choice for the transferring to happen at a predetermined time. [Ex. 1006, 24-29, 38; Ex. 1006, p. 72] See claim element [1d]. [16h] replacing the second set of data in the second database corresponding to the altered portion of the first set of data; See claim element [1e]. [16i] transferring the altered data from the second database to the other first databases; and MALPANI discloses that the second database will transfer the altered data to the other first databases. Each time a database N i sends a propagation message to a database N k, it includes all the updates that it has received that database N k has not received. Therefore, the next 56

69 time the second database sends a propagation message to any of the other plurality of first databases, the second database will transfer to that one of the plurality of first databases all the altered data that it previously received from any of the plurality of first databases. This is the essence of the gossip or epidemic communication model of MALPANI. [Ex. 1006, 24-29;Ex. 1006, pp ] The need for propagation of knowledge in distributed systems is fundamental to most distributed algorithms [17, 3, 9, 13, 11, 5]. In many of these algorithms, the information that needs to be disseminated is required to manage replicated objects, eg., name server tables, routing tables, distributed databases, etc. These objects are replicated primarily to provide fault tolerant and highly available network operations. Most applications involving replicated objects require that all copies of an object be mutually consistent. However, the degree of mutual consistency required may vary depending on the application. Fortunately in many applications pertaining to network management, lazy efforts to update all copies of a replicated object are sufficient. Furthermore, these operations do not require that update information be directly transmitted to all affected sites in a network. Often, update information or the update log can be spread in the form of gossip [13] or epidemic [5] in the network. The latter class of replica synchronization protocols are generally termed as the log propagation protocols where logs contain the accumulated update information [17]. [Ex. 1002, p. 202] 57

70 See claim element [1h]. [16j] replacing the first set of data stored in the other first databases in accordance with the altered portion of the first set of data transferred from the second database. See claim element [1h]. [17a/b] A method as set forth in claim 16 wherein the step of extracting is further defined as storing the altered portion of the first set of data in a redundant database at the first database and transferring the redundant database to the second database and comparing the altered portion of the first set of data in the redundant database with the second set of data stored in the second database. The redundant database is the compressed log extracted from the log in the first statement of the procedure SendTo. The redundant database is subsequently transferred to the second database by the second statement of the procedure SendTo. [Ex. 1006, p. 74] See claim elements [16a], [1d], [12b]. [Ex. 1002, p. 206] [19a/b] A method as set forth in claim 16 further comprising altering by addition, change, deletion or replacement of a portion of the second set of data in the second databases; See claim element [16a]. MALPANI discloses that the first and second databases perform the same synchronization operations. Therefore changes made in a portion of the second set of data in the second databases will be extracted, transferred, and replaced in the first databases in exactly the same way previously discussed. [Ex. 1006, pp ] 58