`
`
`
`
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`__________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________________
`
`DROPBOX, INC.,
`Petitioner,
`
`v.
`
`SYNCHRONOSS TECHNOLOGIES, INC.,
`Patent Owner
`__________________
`
`Case No. IPR2016-00851
`__________________
`
`PETITIONER’S REPLY BRIEF
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`
`
`
`
`
`
`
`I.
`
`D.
`
`TABLE OF CONTENTS
`
`THERE IS NO MEANINGFUL DISPUTE ABOUT THE PERSON
`OF ORDINARY SKILL .................................................................................. 1
`II. NO CLAIM CONSTRUCTION DISPUTES AFFECT THE
`OUTCOME ...................................................................................................... 2
`III. EACH ASSERTED REFERENCE IS A PRIOR ART PRINTED
`PUBLICATION ............................................................................................... 4
`A. Nichols ................................................................................................... 5
`B. Kistler .................................................................................................... 7
`C.
`Burns.................................................................................................... 10
`IV. NICHOLS TEACHES EACH OF THE LIMITATIONS IN THE
`CHALLENGED CLAIMS ............................................................................ 11
`A. Nichols Discloses a “Difference Transaction Generator” ................... 11
`B. Nichols Discloses “a Copy of a Previous State of [the] Data” ........... 12
`C. Nichols Discloses Sending Change Transactions to a Second
`Client ................................................................................................... 13
`The Jupiter Client Incorporates a “Sync Engine,” “Difference
`Transaction Generator,” and “Data Interface” .................................... 16
`Nichols Discloses a “Data File” .......................................................... 17
`E.
`V. KISTLER AND BURNS RENDER THE CLAIMS OBVIOUS .................. 18
`A.
`The POSA Would Incorporate Burns’ Partial-File Transfer into
`Kistler’s Synchronization System ....................................................... 19
`B. Kistler’s Teachings Would Motivate the POSA to Use Delta
`Files ..................................................................................................... 21
`Synchronoss Ignores Lee’s Express Recommendation to Use
`Delta Shipping ..................................................................................... 22
`The Combination of Kistler and Burns Renders Obvious the
`Claimed “System for Synchronizing Data” ........................................ 24
`VI. CONCLUSION .............................................................................................. 25
`
`C.
`
`D.
`
`
`
`i
`
`

`

`
`
`TABLE OF AUTHORITIES
`
`CASES
`
`Allied Erecting & Dismantling Co. v. Genesis Attachments, LLC,
`825 F.3d 1373 (Fed. Cir. 2016) ............................................................................23
`
`ArcelorMittal France v. AK Steel Corp., 811 F. Supp. 2d 960 (D. Del. 2011) ......... 8
`
`Belden Inc. v. Berk-Tek LLC, 805 F.3d 1064 (Fed. Cir. 2015) ................................. 2
`
`Cuozzo Speed Technologies, LLC v. Lee, 136 S. Ct. 2131 (2016) ............................ 3
`
`Dell Inc. v. Acceleron, LLC, 818 F.3d 1293 (Fed. Cir. 2016) ................................... 2
`
`Dickinson v. Zurko, 527 U.S. 150 (1999) .................................................................. 2
`
`Ericsson Inc. v. Intellectual Ventures I LLC, IPR2014-00527, Paper 41
`(P.T.A.B. May 18, 2015) ........................................................................................ 5
`
`Hewlett-Packard Co. v. Mustek Sys., Inc., 340 F.3d 1314 (Fed. Cir. 2003) ...........16
`
`In re Robertson, 169 F.3d 743 (Fed. Cir. 1999) ............................................... 16, 17
`
`MIT v. AB Fortia, 774 F.2d 1104 (Fed. Cir. 1985) ................................................7, 8
`
`O2 Micro Int’l Ltd. v. Beyond Innovation Tech. Co., 521 F.3d 1351
`(Fed. Cir. 2008) ...................................................................................................... 2
`
`Orion IP, LLC v. Hyundai Motor Am., 605 F.3d 967 (Fed. Cir. 2010) ..................... 6
`
`SAS Institute, Inc. v. ComplementSoft, LLC, 825 F.3d 1341 (2016) ......................... 2
`
`Ultratrec, Inc. v. Sorenson Commc’ns, Inc., 2014 WL 4829173
`(W.D. Wis. Sept. 29, 2014) .................................................................................... 8
`
`Valeo N. Am., Inc. v. Magna Elecs., Inc., IPR2014-00220, Paper 59
`(P.T.A.B. May 28, 2015) ......................................................................................10
`
`Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795 (Fed. Cir. 2000) ............ 2
`
`
`
`ii
`
`

`

`
`REGULATIONS
`
`Changes to Implement Inter Partes Review Proceedings, Post-Grant Review
`Proceedings, and Transitional Program for Covered Business Method Patents,
`77 Fed. Reg. 48,680 (Aug. 14, 2012) ..................................................................... 2
`
`Office Patent Trial Practice Guide, 77 Fed. Reg. 48,756 (Aug. 14, 2012) .............10
`
`
`
`
`
`iii
`
`

`

`
`
`Finding there was a reasonable likelihood that the arguments presented in
`
`Dropbox’s petition invalidated the challenged claims, the Board instituted trial as
`
`to claims 16–20, 22–25, 27, and 29 of U.S. Patent No. 6,671,757 (“the ’757
`
`patent”). In response, Synchronoss tries to manufacture deficiencies when none
`
`exist and simply ignores the parts of the petition and the references that contradict
`
`its position. In fact, every limitation of the challenged claims is disclosed in or
`
`rendered obvious by Dropbox’s art, and Synchronoss’s hand-waving does nothing
`
`to show that any of the instituted claims should be upheld.
`
`I.
`
`THERE IS NO MEANINGFUL DISPUTE ABOUT THE PERSON OF
`ORDINARY SKILL
`
`Though Synchronoss challenges Dropbox’s definition of the person of
`
`ordinary skill in the art (“POSA”) as “too vague,” Patent Owner’s Response
`
`(“POR”) at 8, it never explains how this supposed defect affects the invalidity
`
`analysis. Nor does it explain how its own definition materially differs from
`
`Dropbox’s. It does not: Synchronoss’ expert, Dr. Keller, admitted as much in his
`
`deposition, acknowledging that Dropbox’s definition of the POSA was equivalent
`
`to the third of three definitions Dr. Keller provided. Ex. 1034 (“Keller Tr.”) at
`
`217:3-18. Under any of the proffered definitions of the POSA, the challenged
`
`claims are invalid.
`
`
`
`1
`
`

`

`II. NO CLAIM CONSTRUCTION DISPUTES AFFECT THE OUTCOME
`
`Synchronoss next criticizes Dropbox for failing “to construe . . . a number of
`
`critical claim terms, leaving key assumptions that underlie its grounds unspoken.”
`
`POR at 10. This argument is another attempt to create smoke without fire.
`
`The Federal Circuit has held that there is no obligation to construe every—or
`
`even any—term of a patent claim, but “only those” that are “in controversy, and
`
`only to the extent necessary to resolve the controversy.” Vivid Techs., Inc. v. Am.
`
`Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 2000). The PTO has adopted a
`
`similar position: “Petitioners are not required to define every claim term, but
`
`merely to provide a statement that the claim terms are presumed to take on their
`
`ordinary and customary meaning, and to point out any claim term that has a special
`
`meaning and the definitions in the specification.” Changes to Implement Inter
`
`Partes Review Proceedings, Post-Grant Review Proceedings, and Transitional
`
`Program for Covered Business Method Patents, 77 Fed. Reg. 48,680, 48,700 (Aug.
`
`14, 2012).
`
`The cases cited by Synchronoss are not to the contrary. SAS Institute, Dell,
`
`and Belden all deal with the question of whether the PTO could appropriately rely
`
`on a petitioner’s claim construction arguments when the patent owner had no
`
`further opportunity to respond. Dickinson v. Zurko, 527 U.S. 150 (1999), deals
`
`with the Federal Circuit’s power to affirm agency determinations on grounds not
`
`
`
`2
`
`

`

`considered by the agency. And the passage Synchronoss quotes from Cuozzo
`
`Speed Technologies, LLC v. Lee, 136 S. Ct. 2131, 2154 (2016), comes from a
`
`concurrence and is not even about claim construction. Neither Cuozzo nor any
`
`other case holds that an IPR petition must expressly define “critical terms” in order
`
`to put the patentee on adequately particular notice of the grounds, much less
`
`establishes that Dropbox’s petition is somehow deficient.
`
`Moreover, Synchronoss’s own POR adopts the same “ordinary and
`
`customary meaning” definition advanced by Dropbox for all but one term. POR at
`
`11; see Petition at 8. And on that sole term—“difference transaction generator”—
`
`Synchronoss’s definition makes no difference to the claims’ invalidity.
`
`Synchronoss asserts that the broadest reasonable interpretation (“BRI”) of this term
`
`is “software that compares a current state of the data to a previous state of the data
`
`to generate difference information, and then places the difference information into
`
`a difference transaction.” POR at 12. But the inclusion in the sync engines of a
`
`“previous state of [the] data” is a requirement already present in the claims by their
`
`own plain language. In effect, Synchronoss seeks to read that same limitation into
`
`the term “difference transaction generator,” but at most, that interpretation adds a
`
`requirement that the recited “previous state” of the data be used to generate
`
`difference transactions. Synchronoss’s claim construction dispute makes no
`
`
`
`3
`
`

`

`difference because the “previous state” is so used in the asserted prior art. Even
`
`under Synchronoss’s construction, all instituted claims are invalid.
`
`III. EACH ASSERTED REFERENCE IS A PRIOR ART PRINTED
`PUBLICATION
`
`In yet another attempt to latch onto any technicality it believes will dispense
`
`with Dropbox’s petition without having to answer the substance, Synchronoss also
`
`challenges the sufficiency of Dropbox’s proof that the asserted references are prior
`
`art printed publications. Tellingly, Synchronoss never argues (much less provides
`
`evidence) that Dropbox’s references are not such printed publications. To the
`
`contrary, the unrebutted evidence is that each of the references is a paper presented
`
`at an academic computer science conference and published in associated
`
`conference proceedings—a way of publishing that, as Synchronoss’s own expert
`
`testified, is “often” how computer science research is presented, because
`
`“computer science is a fast-moving field,” and conferences are “a quicker way of
`
`getting things out there.” Keller Tr. at 129:24-130:19; see also Ex. 1024 ¶¶ 10-14.
`
`Dropbox’s Petition established these basic facts and, as the Board found,
`
`included “sufficient” evidence that the references were prior art printed
`
`publications. Institution Decision at 11, 21. Synchronoss has provided no contrary
`
`evidence of its own—its expert, Dr. Keller, did not address the issue. Keller Tr. at
`
`145:10-146:23. Yet in search of a get-out-of-jail-free card, Synchronoss quibbles
`
`with virtually every aspect of Dropbox’s evidence, including the supplemental
`
`
`
`4
`
`

`

`evidence Dropbox served in response to Synchronoss’s objections. That evidence
`
`is overwhelming, but if it were incumbent upon Dropbox to erase any reasonable
`
`doubt (the standard is merely a preponderance of the evidence), the additional
`
`evidence submitted with this Reply does so.
`
`A. Nichols
`Synchronoss’s first salvo is a series of arguments that Dropbox failed to
`
`establish that “one of ordinary skill in the art” was in attendance at the UIST 95
`
`conference at which Nichols was presented. POR at 17-19.
`
`At the outset, it makes no difference who attended the conference because
`
`the printed volume of conference proceedings containing Nichols was publicly
`
`distributed before the priority date and is a printed publication. Synchronoss
`
`makes the astonishing suggestion that Prof. Brad Myers, the organizer of the
`
`conference, lacked a basis to testify that this volume “was distributed to all UIST
`
`Conference attendees in 1995” and dismisses as “conclusory” his testimony that it
`
`also was “available for sale immediately after the conference from ACM
`
`publishers” and “was distributed by physical mail in 1995 to libraries and
`
`individuals who had a subscription to the ACM proceedings series.” Ex. 1022 ¶ 5;
`
`see POR at 18-19; Ericsson Inc. v. Intellectual Ventures I LLC, IPR2014-00527,
`
`Paper 41 at 10-11 (P.T.A.B. May 18, 2015) (relying on copyright information of
`
`
`
`5
`
`

`

`IEEE, which like ACM is “a well-known, reputable compiler and publisher”); Ex.
`
`1026.
`
`But there is no need to take Prof. Myers’ word for it. Dropbox also provided
`
`Synchronoss with two separate copies of Nichols from major university libraries,
`
`MIT (Ex. 1032) and Boston University (Ex. 1031). Both copies bear Library of
`
`Congress catalog numbers, and the former is date-stamped 1996, years before the
`
`priority date. See also Ex. 1024 ¶¶ 10-21.
`
`And then there is the conference itself. Professor Myers testified that the
`
`conference was attended by 207 people, including “professionals in the computer
`
`science industry, academics, students, and researchers”—“anyone who was
`
`interested in attending.” Ex. 1022 ¶ 4. Synchronoss’s only answer is to attack the
`
`evidence that the attendees included persons of ordinary skill. POR at 17-18.
`
`Remarkably, it concedes that the attendees that Prof. Myers described could have
`
`been both “below and above the level of ordinary skill.” But of course the POSA
`
`is a hypothetical person, not a real individual who could physically attend a
`
`conference; the evidence, which establishes that the attendees included a wide
`
`cross-section of the interested computer science community, is more than sufficient
`
`to establish the public accessibility of Nichols. See, e.g., Orion IP, LLC v.
`
`Hyundai Motor Am., 605 F.3d 967, 972, 974-75 (Fed. Cir. 2010) (unrebutted
`
`
`
`6
`
`

`

`testimony regarding distribution to 150-200 salespersons sufficient to establish
`
`public accessibility of reference).
`
`B. Kistler
`Synchronoss’s attempt to dispute the publication of Kistler are likewise
`
`unavailing. In addition to the materials previously supplied, evidence from
`
`Kistler’s co-author, Dr. Mahadev Satyanarayanan, and another computer science
`
`professor, Dr. Remzi Arpaci-Dusseau, establish that Exhibit 1006 was published
`
`before the patent’s priority date. Ex. 1036 ¶¶ 1-15; Ex. 1037 ¶¶ 1-13; see also Ex.
`
`1029 (citing Kistler).
`
`Dr. Satyanarayanan testified that Kistler was first presented at ACM’s
`
`Symposium on Operating Systems Principles (“SOSP”) in October 1991, where it
`
`received an “Outstanding Paper” award. Ex. 1036 ¶¶ 11-13. The paper was
`
`collected, along with the other papers presented at SOSP, into a bound volume that
`
`was distributed to all the Symposium’s attendees—about 300 in all. Ex. 1036 ¶ 12.
`
`Because the paper received such acclaim, the authors received requests for copies
`
`from professors around the country following the conference. Ex. 1036 ¶¶ 14-15.
`
`Dr. Satyanarayanan confirmed that Exhibit 1006 is a copy of the paper that he
`
`emailed to colleagues following the conference. Ex. 1036 ¶ 16.
`
`Under existing Federal Circuit law, this is more than sufficient to establish
`
`printed publication status. In MIT v. AB Fortia, for example, the court held that a
`
`
`
`7
`
`

`

`paper presented orally at a conference, provided to the head of the conference, and
`
`then distributed upon request without further restriction to six people, “was a
`
`‘publication.’” 774 F.2d 1104, 1108-09 (Fed. Cir. 1985). District courts have
`
`repeatedly reached the same conclusion when papers have, like Kistler, been
`
`presented at conferences and made available thereafter. See, e.g., Ultratrec, Inc. v.
`
`Sorenson Commc’ns, Inc., 2014 WL 4829173, at *3 (W.D. Wis. Sept. 29, 2014);
`
`ArcelorMittal France v. AK Steel Corp., 811 F. Supp. 2d 960 (D. Del. 2011).
`
`In addition to this overwhelming evidence, Exhibit 1027, which Dropbox
`
`submitted as supplemental evidence in response to Synchronoss’s objections,
`
`further corroborates that Exhibit 1006 is a prior art printed publication. Exhibit
`
`1027 is a copy of the Kistler reference from the ACM’s TOCS journal which was
`
`published in February 1992. The publication of this copy resulted from Kistler’s
`
`selection as “Outstanding Paper” at SOSP. Ex. 1036 ¶ 13. The date of publication
`
`appears on the exhibit, as does a stamp indicating receipt by the University of
`
`Minnesota library on March 17, 1992. Ex. 1027; see also Ex. 1028 (letter from
`
`Univ. of Minnesota confirming date-stamped copy of Ex. 1027). Exhibit 1027 thus
`
`supports the unrebutted proposition that the disclosures on which Dropbox relies
`
`were published long before the priority date.
`
`Synchronoss, in its POR, attempts to elevate form over substance by
`
`imploring the Board not to rely on Exhibit 1027 because it is not identical to
`
`
`
`8
`
`

`

`Exhibit 1006. POR at 42. But Synchronoss makes no attempt to claim that any
`
`difference between Exhibit 1006 and 1027 is relevant to any argument or
`
`disclosure at issue in this proceeding. Nor can it: The content of the two
`
`documents (including all the material relied on) are identical save for an irrelevant
`
`endnote, the formatting, and the quoted length of time of testing the system. Ex.
`
`1036 ¶ 16. And even if the use of a widely praised academic paper as a reference
`
`in an IPR proceeding could be defeated by the use of a PDF of that paper instead of
`
`a photocopy of the original conference proceedings, Synchronoss’s arguments still
`
`fail because the unrebutted evidence, from both testimony and contemporaneous
`
`file metadata, shows that the PDF is prior art. Ex. 1036 ¶¶ 6-16; Ex. 1037 ¶¶ 6-13.
`
`Dr. Satyanarayanan distributed the exact same document to fellow academics, and
`
`Dr. Arpaci-Dusseau both located the document in an Internet search and
`
`distributed it himself on his webpage before the priority date. Ex. 1036 ¶ 15; Ex.
`
`1037 ¶ 10. His web directory is still available online, and shows that “coda-
`
`sosp.pdf,” the very same document submitted as Exhibit 1006, was saved to the
`
`file system by Dr. Arpaci-Dusseau on December 27, 1999. Ex. 1037 ¶¶ 10-11. As
`
`Dr. Arpaci-Dusseau testifies, the actual file that exists in his class directory is even
`
`older than the date it was saved to that directory: the metadata in the PDF
`
`document shows it was created on September 10, 1998. Ex. 1037 ¶¶ 12-13. In
`
`
`
`9
`
`

`

`short, Exhibit 1006 is itself a prior art printed publication, even if one wears
`
`blinders to its provenance.
`
`C. Burns
`Synchronoss makes a similar challenge to the Burns reference, Ex. 1007,
`
`although it takes the striking (and incorrect) position that it can defer its argument
`
`on the merits to a motion to exclude (even though such a motion is “not the proper
`
`venue to challenge” a reference’s status as prior art). Valeo N. Am., Inc. v. Magna
`
`Elecs., Inc., IPR2014-00220, Paper 59, at 11 (P.T.A.B. May 28, 2015); see Office
`
`Patent Trial Practice Guide, 77 Fed. Reg. 48,756, 48,767 (Aug. 14, 2012). Its
`
`position is, in any event, meritless. Dropbox’s prima facie evidence that Burns is a
`
`prior art printed publication was sufficient, as the Board recognized (Institution
`
`Decision at 21), and the additional evidence adduced by Dropbox removes any
`
`conceivable doubt.
`
`As Dr. Thomas Cormen—the Co-General Chair of the IOPADS 97
`
`conference at which Burns was presented—testified (and the face of the article
`
`states), IOPADS 97 was held in San Jose, California. Ex. 1023 ¶ 3. It was
`
`attended by nearly 100 professionals and academics in the computer science field.
`
`Id. And all papers presented there, including Burns, were collected into a bound
`
`volume and distributed to the attendees. Ex. 1023 ¶¶ 4-6. Exhibit 1007 is
`
`photocopy of the article as it appeared in the proceedings. Ex. 1023 ¶ 6.
`
`
`
`10
`
`

`

`IV. NICHOLS TEACHES EACH OF THE LIMITATIONS IN THE
`CHALLENGED CLAIMS
`
`Synchronoss points to various limitations it says, erroneously, are not
`
`disclosed in Nichols. As discussed below, Nichols discloses every claim limitation
`
`and thus anticipates the instituted claims.
`
`A. Nichols Discloses a “Difference Transaction Generator”
`Synchronoss proposes a definition of “difference transaction generator” that
`
`incorporates a requirement that the generator compare a current and previous state
`
`of the data. Synchronoss contends that Nichols does not perform the required
`
`comparison. POR at 23-25. That is wrong; even applying Synchronoss’s
`
`definition, Nichols discloses a “difference transaction generator.”
`
`Synchronoss concedes that the Jupiter system disclosed in Nichols
`
`synchronizes “changes to information” incrementally. POR at 23. The premise of
`
`Synchronoss’s argument is that when Jupiter does this, it merely transmits
`
`“commands such as keyboard strokes or mouse movements” such that they “are
`
`then immediately applied locally” as well as being transmitted, and therefore do
`
`not involve comparing an earlier version of the information to a later one. Id. And
`
`because it is possible to convey changes without a comparison, Synchronoss
`
`argues, Dropbox has failed to show inherent anticipation. POR at 24-25.
`
`Synchronoss misapprehends Dropbox’s argument. Though updating simple
`
`widgets (such as the Numeric widgets on which Synchronoss focuses) may not
`
`
`
`11
`
`

`

`involve a comparison, Synchronoss ignores Nichols’ express disclosure that
`
`“[m]ore complex widgets, such as TextEdits and StrokeEdits, use incremental state
`
`update messages” and its disclosure of what those messages contain. Ex. 1003 at
`
`113-14. For TextEdit widgets, Nichols states that the client sends a message
`
`instructing the server to “replace this region of text with this value.” Ex. 1003 at
`
`114. Such a message contains not merely the user’s inputs or the overall value of
`
`the widget, but instead communicates the text that has changed by reference to the
`
`previous “region.” Ex. 1035 ¶¶ 1-16. It is thus a “difference transaction.” And
`
`because this update message is generated using exactly the comparison that
`
`Synchronoss argues is required, Nichols discloses a “difference transaction
`
`generator” even under Synchronoss’s construction. Ex. 1035 ¶¶ 15-16.
`
`B. Nichols Discloses “a Copy of a Previous State of [the] Data”
`Nichols explains that each client “maintain[s] a full copy of each widget’s
`
`value.” Ex. 1003 at 114. And as discussed above, in at least the case of TextEdit
`
`widgets, the changes, when they are sent, consist of the difference between the
`
`current state of the data and the previous state of said data. Ex. 1035 ¶¶ 8-9, 12-16.
`
`Nichols thus discloses a copy of the previous state of the data. Ex. 1035 ¶ 16.
`
`Moreover, contrary to Synchronoss’s assertions, the previous state of the data and
`
`difference information are present exactly “arranged as in the claim”—just as in
`
`
`
`12
`
`

`

`the ’757 patent, a previous version of the data is used to generate difference
`
`transactions when changes are transmitted. Ex. 1035 ¶¶ 14-16.
`
`C. Nichols Discloses Sending Change Transactions to a Second Client
`Synchronoss argues that Nichols does not send change transactions to the
`
`second client because the system “always sends a different message to the second
`
`client.” POR at 31 (emphasis original). That is wrong.
`
`By way of background, it is undisputed that Nichols teaches sending data
`
`reflecting changes to a widget from one client to a server, then sending the same
`
`changes from the server to a second client. See, e.g., Keller Tr. at 91:4-95:23; Ex.
`
`1002 ¶¶ 42, 58-59, 93-94, 101-102. It is also undisputed that these data are
`
`accompanied by “state information”—numbers representing the number of widget
`
`updates at the client and server that are used to detect conflicts and ensure updates
`
`are processed in order. POR at 32-34; Ex. 1003 at 116 (Nichols’s “protocol labels
`
`each message with the state the sender was in just before the message was
`
`generated”). Synchronoss’s argument is that (1) the term “change transactions”
`
`includes both the changes themselves and the “state information,” (2) the state
`
`information sent from a client to a server always differs from the state information
`
`sent from a server to another client, and (3) because the state information differs,
`
`the claim limitations requiring a second client receiving “the” change transactions
`
`
`
`13
`
`

`

`from the data store (i.e., the very same information sent by the first client) are not
`
`anticipated. See Keller Tr. 94:18-95:11.
`
`This is incorrect for two reasons. First, the “state information” is not part of
`
`a “change transaction.” Synchronoss does not expressly define “change
`
`transaction,” but appears to agree that change transactions consist of changes to
`
`data. Petition at 13 n.2; Ex. 1002 ¶¶ 48-52; POR at 27-28. Nichols teaches that,
`
`absent a conflict, the same information is sent from the first client to the server and
`
`from the server to a second client. Keller Tr. at 91-95. The fact that state
`
`information is also transmitted does not matter—nothing in the claims forecloses
`
`sending additional metadata, such as state information (and virtually any practical
`
`communications protocol will do so), in addition to the changes. Ex. 1035 ¶¶ 17-
`
`20.1
`
`
`1 Synchronoss asserts that Dropbox “acknowledges that the state information
`
`comprises part of the ‘change transactions’ in the Nichols system.” POR at 33.
`
`This assertion is baseless; Dropbox acknowledged that Nichols discloses sending
`
`state information, but that does not mean the state information reads on the
`
`“change transaction” limitation or must be identical across communications with
`
`different clients. It does not.
`
`
`
`14
`
`

`

`Second, Synchronoss is wrong that the state information always differs. In
`
`his declaration, Dr. Keller opined that the state data would always be different as
`
`between a change sent from a first client to the server and the same change sent
`
`from the server to a second client. Ex. 2008 ¶¶ 68-74. But Dr. Keller conceded in
`
`his deposition that sometimes the state information sent from the first client to the
`
`server will, in fact, be the same. Keller Tr. at 207:2-210:5. For instance, where the
`
`very first change was made on a first client, and no changes had been processed by
`
`the server or made on the second client, the state information (reflecting the state
`
`the first client was in before the change was made) sent from the first client would
`
`be “(0,0),” and the server would send this very same state information to the
`
`second client. Id.
`
`On redirect, Dr. Keller tried to retract this admission, asserting that the state
`
`information actually reflects the state of the machine after the change is made. See
`
`Keller Tr. at 307:25-308:16, cf. Ex. 2008 ¶¶ 69-74. Dr. Keller was right the first
`
`time, as Dr. Bestavros explains. Ex. 1035 ¶¶ 21-24. But it does not matter—either
`
`way, Dr. Keller is wrong that the state information sent from client 1 to the server
`
`always differs from the state information sent from the server to client 2, as Dr.
`
`Bestavros’s examples clearly show. Ex. 1035 ¶¶ 25-33. Synchronoss has no
`
`credible evidence to the contrary; Dr. Keller has never even analyzed any
`
`conditions besides the one situation he highlighted in which the information
`
`
`
`15
`
`

`

`happens to differ. Dr. Keller’s testimony stands only for the uncontroversial
`
`proposition—if one incorrectly considers the state information to be part of the
`
`“difference information”—that the information sent by the first client to the server
`
`may sometimes differ from that sent by the server to the second client. This does
`
`not defeat anticipation. See, e.g., Hewlett-Packard Co. v. Mustek Sys., Inc., 340
`
`F.3d 1314, 1326 (Fed. Cir. 2003) (prior art that “sometimes, but not always”
`
`embodies a limitation “nonetheless teaches that aspect of the invention.”). Nichols
`
`teaches a system in which the information is frequently the same.
`
`D. The Jupiter Client Incorporates a “Sync Engine,” “Difference
`Transaction Generator,” and “Data Interface”
`
`Misrepresenting both legal authority and the content of the petition,
`
`Synchronoss argues that Dropbox cannot rely on a multi-functioned software
`
`system to disclose multiple claim elements. None of Synchronoss’s arguments call
`
`into question that these limitations are actually found in Nichols.
`
`Synchronoss asserts that it is improper for Dropbox to rely on a single
`
`system, the Jupiter client, to meet multiple limitations within the claims. That is
`
`wrong. Synchronoss relies on a single case, In re Robertson, 169 F.3d 743 (Fed.
`
`Cir. 1999), to support its assertion that it is “generally considered improper” to rely
`
`on the same structure for separate elements in the claim. POR at 36. Robertson is
`
`inapposite. In Robertson, the patent under consideration included first, second, and
`
`third “mechanical fastening means” of a diaper. Id. at 744. The Federal Circuit
`
`
`
`16
`
`

`

`faulted the Board for finding that a single structure in the art disclosed the
`
`“second” and “third” fastening means because those means were “separate from
`
`and independent of” one another. Id. at 745. The claim here has no analogous
`
`requirement, and Robertson neither states nor implies that it is otherwise improper
`
`for one structure in the prior art to correspond to multiple claim elements.
`
`Claim 1 recites a sync engine that “comprises” several elements that refer to
`
`interrelated portions of a software system: a data interface, a copy of a previous
`
`state of said data, and a difference transaction generator. Ex. 1001 at 47:5-7.
`
`Nichols discloses that the Jupiter system has each of these elements and thus
`
`anticipates. See Pet. at 14-15. Neither law nor logic supports Synchronoss’s
`
`proposition that anticipation requires wholly separate disclosures of each of these
`
`components just because Synchronoss chose to use a multiplicity of overlapping
`
`terms to describe different aspects of the claimed software.
`
`E. Nichols Discloses a “Data File”
`Synchronoss argues that Nichols does not disclose a “data file” as required
`
`by claim 16, apparently because Synchronoss attaches implicit requirements to the
`
`phrase “data file” and then announces that Dropbox has failed to show inherency.
`
`POR at 38-39. “[T]he data representing the widget’s value in Nichols,”
`
`Synchronoss contends, “could simply be distributed throughout the memory”—
`
`apparently as opposed to being on disk. Id. at 39. And the data are not,
`
`
`
`17
`
`

`

`Synchronoss asserts, “collected in the form of blocks.” Id. But Synchronoss never
`
`argues—much less provides evidence—that these are requirements of the term
`
`“file.” Nor can it; as contemporaneous technical dictionaries show, the ordinary
`
`and customary meaning of the term “file” is an exceedingly generic one
`
`(particularly under the BRI)—it is an abstraction meaning only a “named
`
`collection of information,” or a “coherent unit” of data. Ex. 1039. Synchronoss
`
`points to nothing in the specification that suggests that “file” should have some
`
`narrower meaning in claim 16.
`
`Synchronoss’s argument that Dropbox has failed to show inherency is, thus,
`
`a strawman. Dropbox is not arguing inherency; rather, the supposed requirements
`
`that Synchronoss says have not been shown to be “necessarily present,” POR at 39,
`
`are simply not requirements of the claim.
`
`As Dr. Bestavros demonstrated in his original declaration, Nichols discloses
`
`that clients and servers maintain a “full copy of each widget’s value.” Ex. 1002
`
`¶¶ 83-84, 105. That is, as Dr. Bestavros opined, a “data file.”
`
`V. KISTLER AND BURNS RENDER THE CLAIMS OBVIOUS
`
`As the Board recognized in its Institution Decision, the claims should also be
`
`canceled because they would have been obvious over the combination of Kistler
`
`and Burns. Synchronoss’s Response never disputes, nor even engages, the Board’s
`
`observation that if Kistler’s Coda filesystem were to use Burns’s differencing
`
`
`
`18
`
`

`

`technique to send difference information, rather than entire files, the resulting
`
`system would fall within the ins