`
`DROPBOX EX. 1035
`
`DROPBOX EX. 1035
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________________
`
`DROPBOX, INC.,
`Petitioner,
`
`v.
`
`SYNCHRONOSS TECHNOLOGIES, INC.,
`Patent Owner
`__________________
`
`INTER PARTES REVIEW OF U.S. PATENT NO. 6,671,757
`__________________
`
`SECOND SUPPLEMENTAL DECLARATION OF
`AZER BESTAVROS, PH.D.
`
`
`
`Dropbox Ex. 1035
`Page 1
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`
`I, Azer Bestavros, hereby declare and state the following:
`
`1.
`
`I previously provided two declarations in these inter partes reviews:
`
`(1) a declaration, signed on April 7, 2016 (Ex. 1002), and (2) a supplemental
`
`declaration signed on October 24, 2016 (Ex. 1024). I have been asked to provide
`
`the additional testimony herein in response to certain issues discussed in the Expert
`
`Declaration of Dr. Arthur M. Keller In Support of Patent Owner’s Preliminary
`
`Response (Ex. 2001) and the Expert Declaration of Dr. Arthur M. Keller In
`
`Support of Patent Owner’s Response (Ex. 2008), as well as in Dr. Keller’s
`
`deposition (Ex. 1034).
`
`I.
`
`Nichols Teaches a “Difference Transaction Generator” and a “Previous
`State of [the] Data”
`I have been asked to respond to the opinions that Dr. Keller expresses
`2.
`
`with respect to the term “difference transaction generator.” Dr. Keller applies a
`
`different and narrower construction of that term from the one I applied previously:
`
`“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.” Ex. 2008 at 16. Because, Synchronoss contends, the
`
`term “difference transaction generator” requires such a comparison, Nichols does
`
`not disclose this limitation.
`
`3.
`
`I do not believe that Dr. Keller’s definition is the broadest reasonable
`
`interpretation of the term, which is simply something that generates difference
`
`Dropbox Ex. 1035
`Page 2
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`transactions (and which I thus did not previously, and still do not, deem to be in
`
`need of an express construction in this proceeding—that is simply what a
`
`“difference transaction generator” means by its plain terms from the standpoint of
`
`the person of ordinary skill in the art (“POSA”)).
`
`4.
`
`However, as I discuss below, Nichols discloses each element of
`
`claims 1-8, 10-13, 15-20, 22-25, 27, and 29 of U.S. Patent No. 6,671,757 (“the
`
`’757 patent”) even under Synchronoss’s proposed construction.
`
`5.
`
`As discussed in my first declaration, Nichols discloses both simpler
`
`and more complex widgets. Ex. 1002 ¶ 75. Nichols discloses that when simple
`
`widgets are updated, they send the entire value of the widget, whereas complex
`
`widgets aggregate multiple changes and send them all at once in a single message.
`
`Nichols refers to an aggregated set of changes for a complex widget as an
`
`“incremental state update message[].” Id. at 114.
`
`6.
`
`Nichols description of the handling of updates to the complex widget
`
`types would inform the POSA that the Jupiter client compares the current and
`
`previous states of the data prior to sending an incremental state update message.
`
`7.
`
`Nichols discloses that when a widget changes, the client updates the
`
`client display immediately but does not immediately send “low-level keyboard and
`
`mouse events” to the server. Ex. 1003 at 113. Nichols explains that when changes
`
`to a widget’s data are made on the client, those changes are “reflected immediately
`
`Dropbox Ex. 1035
`Page 3
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`in the window.” Ex. 1003 at 114. But those changes are not immediately reflected
`
`on the server. In order to decrease the number of round-trips “for larger scale
`
`widget value updates,” Nichols gathers the changes that result from multiple low-
`
`level events (such as changing the text in a TextEdit widget) and incorporates them
`
`into a single incremental state update message, explained below. Ex. 1003 at 113-
`
`14.
`
`8.
`
`In the case of a TextEdit widget, Nichols also discloses the form that
`
`incremental state update messages take: it discloses that clients and servers
`
`transmit “a general ‘replace this region of text with this value’ message.” Ex. 1003
`
`at 114; see also Ex. 1003 at 118-19 (describing “Replace” message).
`
`9.
`
`In his deposition, Dr. Keller suggested that one way in which
`
`incremental state update messages might be created, consistent with the disclosure
`
`of Nichols, is simply to combine, or “aggregate” multiple low-level keyboard or
`
`mouse events. Keller Deposition Transcript, Ex. 1034 (“Keller Tr.”) at 110-120.
`
`For example, Dr. Keller suggested that a TextEdit widget might aggregate multiple
`
`mouse movements by transmitting the “final result of where I’m putting the
`
`mouse.” Id. at 113:21-25. Likewise, Dr. Keller testified that a replace operation
`
`could be implemented by sending a series of characters or even a sequence of
`
`mouse event values (“mouse click 1,” “mouse move,” “mouse click 2”) followed
`
`by typing a single character. Id. at 116:13-23; 112:17-13. He also testified that a
`
`Dropbox Ex. 1035
`Page 4
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`TextEdit widget might simply aggregate keystrokes by waiting to send keystrokes
`
`“if the user clicks the mouse somewhere else,” then “tak[e] the user input and
`
`send[] it on.” Id. at 117:13-118:11.
`
`10. To the extent Dr. Keller is suggesting that Nichols discloses, or the
`
`POSA might understand, that the Jupiter system simply aggregates keystrokes and
`
`sends them as a group, I disagree. Dr. Keller appears to be opining that because it
`
`is possible for a widget to transmit changes by aggregating and transmitting
`
`keystrokes or mouse movements in such a manner, Nichols fails to anticipate,
`
`because it does not inherently teach the generation of difference information by
`
`comparing an old version of the data to a newer version of the data. See, e.g., id. at
`
`115:11-119:9; 113:18-114:10; 100:13-101:22.
`
`11.
`
`I disagree. The POSA reading Nichols would understand that
`
`TextEdit widgets work—and clients and servers transmit data—by generating
`
`difference transactions, even under Dr. Keller’s definition of the term.
`
`12. Dr. Keller overlooks that Nichols expressly discloses that the only
`
`type of message that is sent by the TextEdit widget is a “Replace” message. Table
`
`3 of Nichols lists the “client messages” and “server messages” associated with
`
`TextEdit widgets—and there is only one type of message listed, “Replace”:
`
`Dropbox Ex. 1035
`Page 5
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`
`Ex. 1003 at 118, tbl.3 (highlighting added). The POSA would understand from
`
`this disclosure that, contrary to Dr. Keller’s suggestions, TextEdit widgets always
`
`transmit “replace” messages that signify “replac[ing] this region of text with this
`
`value.” Ex. 1003 at 114.
`
`13. That understanding is bolstered, moreover, by Nichols’ description of
`
`conflict resolution, which describes the transformation, when necessary because
`
`there have been conflicting edits, of Replace messages. Ex. 1003 at 118-19. There
`
`is no mention of any other type of message, and in fact the discussion of the
`
`various potential types of conflicting messages excludes that possibility. Id.
`
`14. The POSA would understand that creating “replace” messages, as
`
`Nichols discloses, involves exactly the type of comparison that, according to Dr.
`
`Keller, the term “difference transaction generator” requires. That is because
`
`Nichols discloses sending a message indicating what has changed in a region of
`
`text—i.e., a command to replace one region of text with a new block of text. Ex.
`
`Dropbox Ex. 1035
`Page 6
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`Ex. 1003 at 114. To do this, the client (or server) does not simply send the
`
`keystrokes the user has typed (aggregated or not). Rather, it must determine what
`
`has changed since the last message, even if the user has performed a complicated
`
`sequence of operations involving backspaces, cut-and-paste operations, etc. The
`
`POSA would understand, moreover, that to perform that comparison, the
`
`difference transaction generator that Nichols discloses must, at least transiently,
`
`possess a copy of a previous state of the data—as the POSA would understand, that
`
`is how the system determines what text needs to be replaced.
`
`15.
`
`In short, the POSA would understand that what Nichols teaches is
`
`comparing the TextEdit widget’s new value to some previous state, so that the
`
`system can determine what region of text has changed and needs replacing. The
`
`system determines the changes, then transmits a message instructing the recipient
`
`to “replace this region of text with this value”—i.e., a message containing “only
`
`the changes to one system’s data which have occurred on that system (“this value”)
`
`and “instructions for implementing those changes” (“replace this region of text”).
`
`Institution Decision at 6 (defining difference information). That is precisely what,
`
`according to Synchronoss and Dr. Keller, a “difference transaction generator” is
`
`required to do.
`
`16. Nichols thus teaches that the Jupiter client maintains a previous state
`
`of the data so that, whenever the time comes to send aggregated changes to the
`
`Dropbox Ex. 1035
`Page 7
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`server, the client is be able to identify to the server which region of text is to be
`
`replaced. See Ex. 1003 at 114. The POSA would understand that Nichols
`
`discloses a comparison of the current state of the TextEdit’s data (what is reflected
`
`immediately at the client) to the previous state of the data (the widget’s previous
`
`value maintained by the client) so that the client can generate the update message
`
`that identifies which previous data has been changed. Synchronoss’s proposed
`
`construction for “difference transaction generator,” which requires a comparison of
`
`the current state of the data to a previous state of the data is, therefore, disclosed in
`
`Nichols. For the same reason, the claim limitation requiring that each sync engine
`
`include a “previous state of said data” is also met.
`
`II. Nichols Teaches Sending the Same Difference Information from the
`Server to a Second Client as from the First Client to the Server
`17. Dr. Keller has opined that in Nichols the state information sent from a
`
`first client to the server will always be different from the state information sent
`
`from the server to a second client and, therefore, Nichols does not send difference
`
`information to the second client. The premise of Dr. Keller’s argument is
`
`incorrect—there are many circumstances under which the state information will be
`
`the same in both transmissions.
`
`18. Before I address Dr. Keller’s arguments relating to this state
`
`information, it is important to note that the fact that Nichols includes state
`
`information in update messages does not affect whether Nichols discloses sending
`
`Dropbox Ex. 1035
`Page 8
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`difference information. The claims require that a first sync engine that provides
`
`difference information and a second sync engine that receives it. E.g., Ex. 1001 at
`
`46:61-62; 46:66-67. Difference information, moreover, must comprise “only the
`
`changes to one system’s data which have occurred on that system, and instructions
`
`for implementing those changes.” Institution Decision at 6. Nichols sends
`
`difference information, for instance, by sending incremental state update messages
`
`of the form “replace this region of text with this value”—such messages are
`
`changes to one systems’ data and instructions for implementing those changes, i.e.,
`
`difference information. But so long as the only user data that are transmitted are
`
`the “changes . . . which have occurred,” rather than larger portions of the data to be
`
`synchronized, the claims do not prohibit the sending of other information along
`
`with the difference information.
`
`19.
`
`In fact, virtually all network protocols involve the sending of
`
`additional metadata along with whatever data are transmitted, and the POSA would
`
`not understand the definition of “difference information” to be inconsistent with
`
`this typical practice. For example, at a minimum, packet-based network protocols
`
`include metadata in each packet, such as destination address and packet sequence
`
`number, that are used to route the packet to the appropriate destination and
`
`reassemble the data. The ’757 patent clearly contemplates using the disclosed
`
`technology within such a network, as claim 3 discloses the first and second system
`
`Dropbox Ex. 1035
`Page 9
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`are coupled to the server “via an Internet connection.” Ex. 1001 at 47:11-13. The
`
`POSA would not understand that a system that transmitted difference information
`
`along with such address information would fail to meet the limitation of the claims
`
`because it was not transmitting “only” the changes. Similarly, in distributed
`
`systems, messages passed between various computers in the system are often
`
`tagged with sequence numbers or timestamps which are necessary to order such
`
`messages over time or to detect duplicate (or missing) messages. The POSA would
`
`not understand that a system that transmitted difference information along with
`
`such sequence numbers or timestamps would fail to meet the limitation of the
`
`claims because it was not transmitting “only” the changes. The POSA would look
`
`upon the state information included in update messages in the same way; the state
`
`information is not the information to be synchronized, but rather additional
`
`metadata that the system uses to function.
`
`20. Accordingly, the POSA would not understand the state information
`
`that Nichols discloses to be part of the “difference information.” Contrary to Dr.
`
`Keller’s opinions, it therefore makes no difference to my opinions—or to whether
`
`Nichols anticipates the claims—whether the state information is the same or
`
`different when difference information is sent and then retransmitted among
`
`multiple client machines.
`
`
`
`Dropbox Ex. 1035
`Page 10
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`A. Each Client and Server in Nichols Track the Number of Client
`and Server Update Messages It Has Processed in a “State
`Space”
`
`21. Even if state information had to be included in the claimed “difference
`
`information,” however, and the state information had to be identical when
`
`transmitted from a client to a server as when transmitted from the server to a
`
`second client, Nichols discloses a system meeting this requirement. I disagree with
`
`Dr. Keller that “Nichols always sends different ‘difference information’ and
`
`‘change transactions’ to the second client.” Ex. 2008 at 25; see id. at 29.
`
`22. A more detailed description of the state information may be helpful in
`
`explaining why. Nichols discloses that when widget values on clients or servers
`
`are updated, the change is applied locally and the other party is notified. Ex. 1003
`
`at 114. To handle the case where conflicts arise from multiple clients updating a
`
`shared widget, Jupiter utilizes a “state space.” A unique state space exists for each
`
`connection between a client and a server. The state space is simply two values that
`
`represent updates that have been processed by each end of the connection: (1) “c”
`
`is the number of client-updates that have been processed and (2) “s” is the number
`
`of server-updates that have been processed. Ex. 1003 at 115. Jupiter uses the
`
`format “(c, s)” to describe the state space related to a particular client-server
`
`connection. See Ex. 1003 at 115. Thus, if a client “has generated and processed
`
`two messages of its own, and received and processed three from the server,” the
`
`Dropbox Ex. 1035
`Page 11
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`client will be in the state (2, 3). Ex. 1003 at 116. Both the client and server keep
`
`track of the state space between them, and it is possible for them to be in different
`
`states, for instance where the client has processed a message that has not yet been
`
`processed by the server.
`
`23. Every time an update occurs at a client or server, Nichols’ update
`
`protocol labels the outgoing “message with the state the sender was in just before
`
`the message was generated.” Ex. 1003 at 116. Thereafter, the sender updates its
`
`state by adding 1 to the appropriate c or s value.
`
`24.
`
`In his deposition, Dr. Keller opined that the state information that is
`
`sent represents the state the updating machine is in before the update is applied.
`
`Keller Tr. at 207. I agree. Using this convention, he agreed that the state
`
`information sent from a client to a server is sometimes the same as that sent from a
`
`server to a second client. Keller Tr. at 207-210. Even if the state information is
`
`considered to be part of the difference information, he therefore confirmed my
`
`opinion that the second sync engine disclosed in Nichols is “coupled to receive the
`
`difference information” that was provided by the first sync engine (see claim 1),
`
`and similarly, the second device is coupled to receive the “data change
`
`transactions” that were provided by the first device (see claim 16).
`
`25. But even if, as Dr. Keller suggested during his redirect examination,
`
`the state information instead reflects the state the updating machine is in after the
`
`Dropbox Ex. 1035
`Page 12
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`update is applied, there are likewise circumstances in which the state information
`
`sent from the first client to the server is identical to that sent from the server to the
`
`second client, and Dr. Keller is therefore mistaken that the state information
`
`“always” differs.
`
`26. The two examples below address both circumstances and show that
`
`the state information sent to the second client can, in fact, be the same as the state
`
`information sent by the first client, under either convention.
`
`27. Example 1: Updated Machine Sends Pre-Update State Data.
`
`Consider the following slight modification to the hypothetical given in paragraphs
`
`68 to 74 of Dr. Keller’s declaration, which shows that state information for the
`
`message sent from the first client to the server can be the same as the state
`
`information sent from the server to the second client. Assume, in accordance with
`
`Dr. Keller’s original testimony, that when a machine sends an update, it also sends
`
`the state information reflecting its state prior to the time at which the change was
`
`made. E.g., Keller Tr. at 206:11-207:1; 208:23-209:5; 205:3-20. Assume further
`
`that Client 1 (C1) had previously processed no messages from server S and server
`
`S had processed no messages from C1. Thus, C1 would be in state (0, 0). Assume
`
`further that the server had processed no messages from Client 2 (C2) and had not
`
`sent any messages on to client C2 for processing. Thus, relative to C2, the server
`
`would be in state (0, 0).
`
`Dropbox Ex. 1035
`Page 13
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`28. Now, assume C1 makes a change and no changes are processed from
`
`the server S. This would increment the client’s state number to 1, bringing its state
`
`to (1, 0). But under Dr. Keller’s initial assumption, C1 will send the state data
`
`reflecting its state before the change was made (i.e., (0, 0)) along with the
`
`information to update the widget’s value to the server in a message M1 (to use Dr.
`
`Keller’s notation).
`
`29. Server S will update its value for the widget. Server S will now have
`
`an update that C2 does not have, and will be in state (1, 0) relative to C2.
`
`However, because it sends the state data reflecting its state before the change was
`
`made, it will send (0, 0) to C2, along with the information to update the widget’s
`
`value. Thus, the state information sent from client C1 to server S will be (0, 0) and
`
`the state information sent from server S to client C2 will also be (0, 0).
`
`30. Assuming no further updates had been exchanged between the server
`
`and C2. When the server receives and processes the message, it will now have a
`
`change that C2 does not have, which will require it to update its state number
`
`relative to C2 to 1. Thus, when it propagates to C2 the message received from C1,
`
`the server will send the message and the state value (1, 1). This is exactly the
`
`message the server received from C1. The following diagram is an annotated
`
`modification of the diagram used by Dr. Keller, which illustrates Example 1,
`
`Dropbox Ex. 1035
`Page 14
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`described above, and shows that state information (0, 0) is sent from C1 to S and
`
`from S to C2.
`
`
`
`31. Example 2: Updated Machine Sends Post-Update State Data.
`
`Consider an alternative scenario which addresses Dr. Keller’s alternative position.
`
`Assume that when a machine sends an update, it also sends the state information
`
`reflecting the state it is in after the change has been made. Assume further that
`
`Client 1 (C1) had previously processed one message from server S and server S
`
`had processed no messages from C1. Thus, C1 and S would be in state (0, 1).
`
`Assume further that server S had processed one message from Client 2 (C2) and
`
`had not sent any messages on to C2 for processing. Thus, relative to C2, server S
`
`would be in state (1, 0).
`
`Dropbox Ex. 1035
`Page 15
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`32. Now, assume C1 makes a change and no changes are processed from
`
`server S. This would increment C1’s client state number to 1, bringing its state to
`
`(1, 1). C1 will send the message M1 and the state information (1, 1) to server S.
`
`When server S receives and processes the message, it will now have a change that
`
`C2 does not have, which will require it to update its server state number relative to
`
`C2 to 1. Thus, server S’s state information relative to C2 is (1, 1) after it has made
`
`the change. When it sends M2 to C2, the server will send the message and the
`
`state value (1, 1). This is exactly the same message the server received from C1.
`
`The following diagram is also an annotated modification of the diagram used by
`
`Dr. Keller, which illustrates the Example 2, described above, and shows that state
`
`information (1, 1) is sent from C1 to S and from S to C2.
`
`
`
`Dropbox Ex. 1035
`Page 16
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`33. Dr. Keller admits that he did not consider any case where the state
`
`information sent from the client to the server and then sent on to a second client
`
`was either (0, 0) or (1, 1). Keller Tr. at 379-385. As the two previous hypothetical
`
`examples illustrate, the information sent from the first client to the server can be
`
`identical to the information sent from the server to the second client. Because
`
`there are conditions (such as those in the examples given above) in which the state
`
`information sent from the first client is the same as the state information received
`
`by the second client, and for the additional reasons given in my first declaration, it
`
`is my opinion that the POSA would understand that Nichols teaches sending the
`
`same difference information to a second client that was provided by the first client,
`
`even if state information is considered to be part of the difference information
`
`recited in the claims.
`
`*
`
`*
`
`*
`
`34.
`
`I understand that this declaration will be filed as evidence in a
`
`contested case before the Patent Trial and Appeal Board of the United States Patent
`
`and Trademark Office. I also understand that I may be subject to cross-
`
`examination concerning this declaration, and I will appear for cross-examination, if
`
`required of me, during the time allotted for cross-examination.
`
`35.
`
`I hereby declare that all of the statements made herein of my own
`
`knowledge are true and that all statements made on information and belief are
`
`Dropbox Ex. 1035
`Page 17
`
`
`
`Cases IPR2016-00850, IPR2016-00851
`Patent 6,671,757
`believed to be true; and further that these statements were made with knowledge
`
`that willful false statements and the like so made are punishable by fine or
`
`imprisonment, or both, under Section 1001 of Title 18 of the United States Code.
`
`
`
`Date: April 28, 2017
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`_____________________
`Dr. Azer Bestavros
`
`
`
`Dropbox Ex. 1035
`Page 18
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
