Ipr2015 00874

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
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
V.
VI.
A.
Grounds for Standing ............................................................................3
B.
Statement of Precise Relief Requested (37 C.F.R. 42.22(a))

and Identification of Challenges (37 C.F.R. 42.104(b)) ....................3
C.
How the Construed Claims are Unpatentable under the

Statutory Grounds identified in 37 C.F.R. 42.104(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
FACTUAL BACKGROUND..........................................................................5
A.
Declaration Evidence ............................................................................5
B.
The State of the Art as of 1995 .............................................................6
C.
The Challenged 506 Patent ..................................................................6
CLAIM CONSTRUCTION (37 C.F.R. 42.104(b)(3)).................................8

A. Support For Claim Construction ......................................................9
ii
VII. THE GROUNDS SHOWING THAT PETITIONER HAS A

REASONABLE LIKELIHOOD OF PREVAILING ....................................11
A.
Everson 094 Patent Overview ............................................................11
B.
Malpani Overview ...............................................................................15
C.
Element by Element Analysis Demonstrating How Everson

Anticipates Claims 1-6, 8, 9, 12, 15-17, and 19 of the 506
Patent ...................................................................................................19
[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: .....................................................................................19
[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; ....................................................................21
[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; ..................................................................................24
[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; .......................................................................25
[1e] replacing the data in the second database corresponding to
the altered portion of the data; .......................................................25
[1f] wherein transferring only the altered portion of the data
further includes; .............................................................................26
iii
[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 ..............26
[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. ......................27
[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. .....................................28
[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: ...................................................29
[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 .....................................................................29
[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, ........................................29
[3d] wherein the modification identification includes a
modification field associated with the data;...................................30
[3e] identifying an altered portion of the data that has the
being altered, ..................................................................................30
[3f] transferring only the altered portion of the data from the
first database to the second database,.............................................30
[3g] receiving a confirmation message at the first database from
the second database, .......................................................................30
iv
[3h] and replacing the data in the second database associated

with the altered portion of the data. ...............................................30
[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. ..............................30
[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. ...................................................................31
[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. .................................................................31
time of a previous database synchronization. ................................31
[9a/b] The system as recited in claim 5, wherein the central
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. ..........................................................................................31
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. ..............................32

processing unit, upon receiving the confirmation message, is
further operative to update the date and time of the database
synchronization. .............................................................................33
[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; .........................................................33
[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; .........................................33
[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; .......................................................................................34
[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
[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
being altered; ..................................................................................34
[16g] transferring only the altered portion from the one of first
databases to the second database at a predetermined time; ...........34
[16h] replacing the second set of data in the second database
corresponding to the altered portion of the first set of data; ..........35
[16i] transferring the altered data from the second database to
the other first databases; and ..........................................................35
vi
[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. ..........................36
[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. ............................................36
[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;.............36
[19c] extracting the portion of the second set of data that has
been altered in the second database; ..............................................37
[19d] transferring only the altered portion from the second
databases to the plurality of first databases at a
predetermined time; and.................................................................37
[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. ..........................................................................37
D.
Element by Element Analysis Demonstrating How Malpani

Anticipates Claims 1-6, 8, 9, 12, 13, and 15 of the 506 Patent .........38
[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: .....................................................................................38
[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
databases to a modification identification associated with a

prior synchronization; ....................................................................40
[1c] identifying an altered portion of the data that has the
being altered; ..................................................................................42
[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; .......................................................................43
[1e] replacing the data in the second database corresponding to
the altered portion of the data; .......................................................44
[1f] wherein transferring only the altered portion of the data
further includes; .............................................................................44
[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 ..............44
[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. ......................46
confirmation message further comprises updating the date
and time of the database synchronization. .....................................47
[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: ...................................................48
[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 .....................................................................48
viii
[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, ........................................49
[3d] wherein the modification identification includes a
[3e] identifying an altered portion of the data that has the
being altered, ..................................................................................50
[3f] transferring only the altered portion of the data from the
first database to the second database,.............................................50
[3g] receiving a confirmation message at the first database from
the second database, .......................................................................50
[3h] and replacing the data in the second database associated
with the altered portion of the data. ...............................................50
modification identification field is automatically updated to
reflect when any portion of the data is altered. ..............................50
[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. ...................................................................51
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. .................................................................51
ix

time of a previous database synchronization. ................................52
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. ..........................................................................................52
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. ..............................52
processing unit is further operative to transfer identification
information identifying the first database. .....................................53
processing unit, upon receiving the confirmation message, is
further operative to update the date and time of the database
synchronization. .............................................................................53
[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; .........................................................55
[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; .........................................55
[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; .......................................................................................55
[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
[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
being altered; ..................................................................................55
databases to the second database at a predetermined time; ...........56
corresponding to the altered portion of the first set of data; ..........56
[16i] transferring the altered data from the second database to
the other first databases; and ..........................................................56
[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. ..........................58
[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. ............................................58
[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;.............58
[19c] extracting the portion of the second set of data that has
been altered in the second database; ..............................................59
xi
[19d] transferring only the altered portion from the second

databases to the plurality of first databases at a
predetermined time; and.................................................................59
[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. ..........................................................................59
VIII. CONCLUSION..............................................................................................60
xii
I.
INTRODUCTION
Pursuant to the provisions of 35 U.S.C. 311-319, 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 techniquesdatabase synchronization using timestampsthat 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 Unifieds participation in this proceeding, the filing of this
petition, or the conduct of any ensuing trial. See Ex. 1005.
1
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-00005 (EDTX, filed
1/5/2015)
2. Hall Data Sync v. Dropbox, Inc., 2-15-cv-00003 (EDTX, filed 1/5/2015)
3. Hall Data Sync v. Box Inc., 2-15-cv-00002 (EDTX, filed 1/5/2015)
4. Hall Data Sync v. Google Inc., 2-15-cv-00004 (EDTX, filed 1/5/2015)
5. Hall Data Sync v. Apple Inc., 2-15-cv-00006 (EDTX, filed 1/5/2015)
6. Hall Data Sync v. Microsoft Corp., 2-15-cv-00021 (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:
Address:
Michael L. Kiklis
Oblon LLP
1940 Duke Street
Alexandria, VA 22314
Email:
cpdocketkiklis@oblon.com
Telephone: (703) 413-2707/(703)413-3000 (main)
Fax:
(703) 413-2220
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. 15-0030.
IV.
REQUIREMENTS FOR INTER PARTES REVIEW

As set forth below and pursuant to 37 C.F.R. 42.104, each requirement for
inter partes review of the 506 Patent is satisfied.

A.
Grounds for Standing
Petitioner certifies pursuant to 37 C.F.R. 42.104(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. 42.22(a)) and

Identification of Challenges (37 C.F.R. 42.104(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.
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, 10-12 October
1989, Mineapolis, MN. Print ISBN: 0-8186-1968-6. Pages 202-211.
(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. 42.104(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. 42.104(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.
42.104(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
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. 1002-1003 (Ex. 1006,
pp. 15-70). 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.
1006. This Petition is also supported by the declaration of Ms. Jodi Gregory who
5
testifies that Exs. 1002 and 1004 were publicly available before February 13, 1994.
See Ex. 1007.
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.Dates seminal treatise An Introduction to Database Systems (1st
edition 1981) also discussed synchronization and various techniques for solving
this problem. That is why in 1989the publication date of Malpaniand in 1991
the filing date of Eversonthe 506 Patents database synchronization technique
was disclosed. Dr. Hutchinson provides a more detailed overview of the state of
the art in Ex. 1006, 21-22.
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
Johnson, Paul R. and Thomas, Robert H., The Maintenance of Duplicate
Databases, Internet Request for Comments #677, January 27, 1975. Available
from: https://tools.ietf.org/html/rfc677
6
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
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. 42.104(B)(3))

Pursuant to 37 C.F.R. 42.204(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
(claims 3-15)
Modification
identification (all claims)
Modification field
(claims 1, 3, 4, 5, 16)
A.
Any information related to a modification

Information included in the modification
identification
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
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
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.
Hutchinsons declaration provides a much more comprehensive overview. Ex.
1006, 23-35.
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:4165. Fig. 4 provides an overview of Everson:
11
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
stamps. Ex. 1001, 3:41-66.

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, 81-85.
Moreover, Eversons 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
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:57-60. 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
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 30-35 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. 202. 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
modification field because it indicates the time the associated data was modified.
Ex. 1006, 25; Ex. 1002, p. 204.
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 datas 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 (Li) that includes all changes
anywhere within the distributed database as well as a time table (Ti ) which is a two
dimensional array that reflects that nodes knowledge of all updates within the
16
system. Dr. Hutchinson created the following diagram to better illustrate this
concept:
Dr. Hutchinson explains:

When the entry Ti[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 ls
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, Ti[*, i].
The entry in that column at position k (when Ti[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 Ti[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
receivers log. The propagation message also contains a copy of the
senders time table. When a sender node i sends a message to node k
17
with Ti[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, 25-26.
Each node periodically propagates updates throughout the network. Each
update includes a compressed log (Li) which includes only those updates that the
receiving node needs, based on a timestamp comparison using Ti, and includes the
senders time table. Such propagation messages serve two purposes (1) to update
the receiving nodes 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 senders 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 Ti[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, 25-27.
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. 202. Also, because [p]ropagation of information, as
18
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.
202. 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. 102. For ease of reference, this analysis
includes letters for the individual claim elements (e.g., 1a). This analysis is a
presentation of Dr. Hutchinsons analysis from his claim chart in his declaration,
although shortened in various places. Ex. 1006, pp. 34-54. Text in italics is
explanatory testimony from Dr. Hutchinsons claim chart (i.e., his testimony). Id.
All other text below are direct quotes from Ex. 1003.
[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
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
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
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
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
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
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
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]

24
[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. 1006 p. 39]
25

[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. 1006 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. 1006 p. 40]

One of ordinary skill in the art would recognize that the
CONFIRMED LU6.2 verb means that the claimed confirmation
26
message is necessarily present because that is the functionality of this

verb. See for example: Ex. 1004, p. 37, 46, 74, 81-85. [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. 40-41]
Since the invention for synchronizing the databases to be

described herein is the same for all network structures, the
27
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:49-55.
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
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]
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
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 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,
[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.
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
See claim element [1b], [2b].

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]
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].
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
31
synchronization with the date/time modification identification item associated

with the data.
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.
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]
32

When received by the second database, the code at lines 20-31 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]

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

[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;
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]

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, 30-35 ;Ex. 1006, p. 50]
34

following data: TLC=time last called. (A time stamp of the last
time a successful conversation was completed normally with TP2).
3:17-32]
Ex. 1003, Fig. 4.

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
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
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.
[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;
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
p. 53]
[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].
following data: TLC=time last called. (A time stamp of the last time
a successful conversation was completed normally with TP2).
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.
37
modify, just like the first databases do. Therefore changes made in a
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
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. 102. For ease of reference, this analysis includes
letters for the individual claim elements (e.g., 1a). This analysis is a presentation
of Dr. Hutchinsons analysis from his claim chart in his declaration, although
shortened in various places. Ex. 1006, pp. 54-69. Text in italics is explanatory
testimony from Dr. Hutchinsons claim chart (i.e., his testimony). Id. All other
text below are direct quotes from Ex. 1002.
[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
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
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,
modification field associated with that data.
which
includes
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
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
prior
synchronization of a node i with a node k is in the time table

associated with node i (Ti) at position k, i; that is Ti[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. 56-57]
This algorithm is based on the simple idea that if a site Ni knows that
another site Nj knows about event e then there is no need for Ni to
include e in any of its future log propagation messages destined to Ni.
In order to incorporate a sites knowledge about other sites
knowledge a two dimensional time table, Ti, of local clocks of each
site is maintained. The algorithm maintains each sites time table Ti
such that it satisfies the time table property. The time table property
requires that when Ti[ k , l ] = , Ni can assume that Nk has heard of at
least all those events that have occurred at Nl up to Nls 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
then Ni is certain that Nk already knows about event e. [Ex. 1002, pp.
205-6]
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 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 Ni as Li, and the
altered portion of the data as the compressed log Li. [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 Nk, Ni first discards all those events from Li that are
already known to Nk. The resulting compressed log Li and Ti are
transmitted to Nk. [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
subsequent to the prior synchronization modification identification as

a result of being altered. First the altered portion of the data Li is
identified, and then it is sent to the other node (Nk). [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 Nk, Ni first discards all those events from Li that are
already known to Nk. The resulting compressed log Li and Ti are
transmitted to Nk. [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 Ni and the second database is Nk. As described in 27
above, the HasReceived function determines if the destination node k
has already seen an event from node i's log Li. Each event that hasnt
already been seen by node k is included in the compressed log Li,
which, along with the time table, is then sent to node k. [Ex. 1006, p.
59]
43
[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 Li, and data appended to Li replaces data earlier in the
log. [Ex. 1006, 24-29; Ex. 1006, p. 59]
When Ni receives a propagation message, the events in the message
are appended to Li. The entries in Ti are updated by using Tk such that
they reflect the current knowledge of Ni after receiving the
propagation message.
[Ex. 1002, pp. 205-6](emphasis added)

[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
MALPANI discloses that the first database receives a confirmation
44
message that the second database received the altered portion of the
data.
After database Nj receives a propagation message from a
database Ni, each message that database Nj sends to Ni will confirm

that it has received the altered portion of the data which Ni 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 Ti. Each message that it sends includes Ti,
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 Ti[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]
45
[Ex. 1002, pp. 205-6](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.
MALPANI also replaces the data stored in each one of the other
plurality of first databases. Each time a database Ni sends a
propagation message to a database Nk, it includes all the updates that
it has received that database Nk 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]
46

application.
[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. 2
1002, p. 202] (emphasis added)
confirmation message further comprises updating the date and time of the
database synchronization.
See claim elements [1a], [1g].
47
MALPANI discloses that the date and time of the database

synchronization is stored in the time table Ti, and Ti is updated each
time a confirmation message is received. [Ex. 1006, 24-29; Ex.
1006, p. 62]
[Ex. 1002, pp. 205-6]

[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
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. 63-64]
An event model of execution is used, i.e., we consider an execution in
48
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.
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]
[3d] wherein the modification identification includes a modification field
associated with the data;
event, where:
49

[3e] identifying an altered portion of the data that has the 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,
See claim element [1g].
[3h] and replacing the data in the second database associated with the
altered portion of the data.
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].
50
event, where:
[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.
operations. [Ex. 1002, pp. 204](emphasis added)
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.
51

operative to determine a date and time of a previous database
synchronization.
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.
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.
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 Li, which is
prepared on the first database and transferred to the second database.
[Ex. 1006, p. 68]
52
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. 205-6]; See claim element [1e].

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]

unit, upon receiving the confirmation message, is further operative to update
the date and time of the database synchronization.
53
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

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. Hutchinsons analysis from his claim
chart in his declaration, although shortened in various places. Ex. 1006, pp. 69-75.
Text in italics is explanatory testimony from Dr. Hutchinsons claim chart (i.e., his
testimony). Id. All other text below are direct quotes from Ex. 1002.
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
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;
[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]
[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;
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
subsequent to the prior synchronization modification identification as

a result of being altered is the compressed log Li. The SendTo
procedure first extracts this data into the compressed log, and
subsequently sends it to Nk. [Ex. 1006, p. 72]
[Ex. 1002, p. 206]

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]
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
MALPANI discloses that the second database will transfer the altered
data to the other first databases. Each time a database Ni sends a
propagation message to a database Nk, it includes all the updates that
it has received that database Nk has not received. Therefore, the next
56
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. 72-73]
application.
[17]. [Ex. 1002, p. 202]
57

[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.
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]
[Ex. 1002, p. 206]

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;
MALPANI discloses that the first and second databases perform the
same synchronization operations.
Therefore changes made in a

the same way previously discussed. [Ex. 1006, pp. 74-75]
58

[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
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. See 24-29 and 38 above. Its an obvious
matter of design choice to transfer messages at a predetermined time.
[Ex. 1006, 24-29, 38; Ex. 1006, p. 75].
See claim element [1d], [16g].
[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.
MALPANI discloses that the first and second databases perform the
same synchronization operations.
Therefore changes made in a

the same way previously discussed. [Ex. 1006, p. 75]
See claim elements [1e], [19b].
59
VIII. CONCLUSION
For the reasons set forth above, Petitioner has established a reasonable
likelihood of prevailing with respect to at least one claim of the 506 Patent.
Therefore, Petitioner respectfully requests that the Patent Trial and Appeal Board
institute an inter partes review and then proceed to cancel claims 1-6, 8, 9, 12, 13,
15-17, and 19.
Respectfully submitted,
OBLON LLP
Dated: March 11, 2015
/Michael L. Kiklis/
Michael L. Kiklis
Reg. No. 38,939
Customer Number
22850
Tel. (703) 413-3000
Fax. (703) 413-2220
60
Petitioners Exhibit List (March 11, 2015)
PETITIONERS EXHIBIT LIST

March 11, 2015
Exhibit
Description
Ex. 1001
U.S. Patent No. 7,685,506
Ex. 1002
Ambarish Malpani and Divyakant Agarwal, Efficient

Information Dissemination in Computer Networks. Proceedings
of the 14th Conference on Local Computer Networks, 10-12
October 1989, Mineapolis, MN. Print ISBN: 0-8186-1968-6.
Pages 202-211. (Malpani)
Ex. 1003
U.S. Patent No. 5,261,094 to Everson (Everson)
Ex. 1004
LU 6.2 API Application Programmers Reference Manual HP

3000 MPE/iX Computer Systems Edition 3, Hewlett Packard,
Manufacturing Part Number: 30294-90008 E0692, U.S.A., June
1992.
Ex. 1005
Petitioners Voluntary Interrogatory Responses
Ex. 1006
Declaration of Norman Hutchinson, Ph.D.
Ex. 1007
Declaration of Ms. Jodi Gregory
Ex. 1008
Selected pages from the prosecution history of U.S. Patent No.

7,685,506
61
CERTIFICATE OF SERVICE
The undersigned certifies service pursuant to 37 C.F.R. 42.6(e) and
42.105(b) on the Patent Owner by Express Mail of a copy of this Petition for Inter
Partes Review and supporting materials at the correspondence address of record
for the 506 patent as well as counsel of record in the district court litigations:
HOWARD & HOWARD ATTORNEYS PLLC
450 West Fourth Street
Royal Oak, MI 48067
Hao Ni
Ni Law Firm, PLLC
8140 Walnut Hill, Ste 310
Dallas, TX 75231
Dated: March 11, 2015
By:
/Michael L. Kiklis/
Michael L. Kiklis
Reg. No. 38,939

Ipr2015 00874

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ipr2015 00874

Uploaded by

Copyright:

Available Formats

UNITED STATES PATENT AND TRADEMARK OFFICE

MANDATORY NOTICES .............................................................................1

Real Party-in-Interest ............................................................................1

The Patent Owner ..................................................................................2

Identification of Lead and Back-Up Counsel........................................2

Service Information ...............................................................................2

PAYMENT OF FEES .....................................................................................3

REQUIREMENTS FOR INTER PARTES REVIEW ......................................3

Grounds for Standing ............................................................................3

Statement of Precise Relief Requested (37 C.F.R. 42.22(a))

How the Construed Claims are Unpatentable under the

Threshold Showing of Reasonable Likelihood That Petitioner

Declaration Evidence ............................................................................5

The State of the Art as of 1995 .............................................................6

The Challenged 506 Patent ..................................................................6

CLAIM CONSTRUCTION (37 C.F.R. 42.104(b)(3)).................................8

VII. THE GROUNDS SHOWING THAT PETITIONER HAS A

Everson 094 Patent Overview ............................................................11

Malpani Overview ...............................................................................15

Element by Element Analysis Demonstrating How Everson

[1g] receiving a confirmation message at the one of the plurality

[3h] and replacing the data in the second database associated

[15a/b] The system as recited in claim 3 wherein the central

Element by Element Analysis Demonstrating How Malpani

databases to a modification identification associated with a

[3c] a central processing unit associated with the first database

been altered, is further operative to determine a date and

[16e] comparing a modification identification associated with

[19d] transferring only the altered portion from the second

Pursuant to 37 C.F.R. 42.8(b)(1), Petitioner certifies that Unified is the real

The Patent Owner

Identification of Lead and Back-Up Counsel

Pursuant to 37 C.F.R. 42.8(b)(3), Petitioner provides the following

Pursuant to 37 C.F.R. 42.8(b)(4), papers concerning this matter should be

REQUIREMENTS FOR INTER PARTES REVIEW

inter partes review of the 506 Patent is satisfied.

Grounds for Standing

Petitioner certifies pursuant to 37 C.F.R. 42.104(a) that the 506 Patent is

Statement of Precise Relief Requested (37 C.F.R. 42.22(a)) and

Petitioner requests inter partes review and cancellation of claims 1-6, 8, 9,

Claims 1-6, 8, 9, 12, 15-17, and 19 are anticipated under 35 U.S.C.

102(b) by U.S. Patent No. 5,261,094 (the 094 patent) to Everson

Claims 1-6, 8, 9, 12, 13, and 15 are anticipated under 35 U.S.C.

How the Construed Claims are Unpatentable under the Statutory

The challenged claims are to be construed as indicated in Section VI, below.

are provided in Section VII, below, in the form of an analysis.

Threshold Showing of Reasonable Likelihood That Petitioner

Information presented in this Petition, including the unpatentability grounds

This Petition is supported by the declaration of Professor Norman

The State of the Art as of 1995

The Challenged 506 Patent

With barely more than a column devoted to database synchronization, the

Johnson, Paul R. and Thomas, Robert H., The Maintenance of Duplicate

example, in a distributed database environment, the patent claims comparing

CLAIM CONSTRUCTION (37 C.F.R. 42.104(B)(3))

shall receive the broadest reasonable construction in light of the specification of

Any information related to a modification

Support For Claim Construction

Database: Webster's College New World Dictionary (Fourth Edition)

stamps. Ex. 1001, 3:41-66.

Dr. Hutchinson explains:

soon as it becomes known . . . is prohibitively expensive, sending updates

to databases distributed throughout a computer network. The use of