IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`PATENT TRIAL & APPEAL BOARD
`
`
`
`
`
`
`
`In re Patent of: Peter Dickenson
`U.S. Patent No.: 6,738,799
`Issue Date:
` May 18, 2004
`Appl. No.:
`
`10/452,156
`Filing Date:
`
`June 2, 2003
`Title:
`Methods and Apparatuses for File Synchronization and
`Updating Using a Signature List
`
`
`
`DECLARATION OF PROFESSOR TODD C. MOWRY, Ph.D.
`
`Background and Qualifications
`
`
`I, Prof. Todd C. Mowry, Ph.D., declare as follows:
`
`I.
`
`
`(1.) My name is Todd Mowry. I am a Professor at Carnegie Mellon
`
`University in the Computer Science Department. I have studied and practiced in
`
`the field of computer science for over 20 years, and have been a professor of
`
`computer science since 1993.
`
`(2.)
`
`I received my Doctor of Philosophy (Ph.D.) degree in the field of
`
`Electrical Engineering from Stanford University in 1994. I received my Masters of
`
`Science (M.S.) degree in Electrical Engineering from Stanford University and my
`
`Bachelor of Science (B.S.) degree in Electrical Engineering from the University of
`
`Virginia.
`
`(3.) Upon receiving my Ph.D. degree, I joined the faculty of the University
`
`of Toronto in the Department of Electrical and Computer Engineering and the
`
`
`
`‐ 1 ‐
`
`Oracle Exhibit 1008
`
`
`PATENT TRIAL & APPEAL BOARD
`
`
`
`
`
`
`
`In re Patent of: Peter Dickenson
`U.S. Patent No.: 6,738,799
`Issue Date:
` May 18, 2004
`Appl. No.:
`
`10/452,156
`Filing Date:
`
`June 2, 2003
`Title:
`Methods and Apparatuses for File Synchronization and
`Updating Using a Signature List
`
`
`
`DECLARATION OF PROFESSOR TODD C. MOWRY, Ph.D.
`
`Background and Qualifications
`
`
`I, Prof. Todd C. Mowry, Ph.D., declare as follows:
`
`I.
`
`
`(1.) My name is Todd Mowry. I am a Professor at Carnegie Mellon
`
`University in the Computer Science Department. I have studied and practiced in
`
`the field of computer science for over 20 years, and have been a professor of
`
`computer science since 1993.
`
`(2.)
`
`I received my Doctor of Philosophy (Ph.D.) degree in the field of
`
`Electrical Engineering from Stanford University in 1994. I received my Masters of
`
`Science (M.S.) degree in Electrical Engineering from Stanford University and my
`
`Bachelor of Science (B.S.) degree in Electrical Engineering from the University of
`
`Virginia.
`
`(3.) Upon receiving my Ph.D. degree, I joined the faculty of the University
`
`of Toronto in the Department of Electrical and Computer Engineering and the
`
`
`
`‐ 1 ‐
`
`Oracle Exhibit 1008
`
`
`
`Department of Computer Science as an Assistant Professor. I relocated and was
`
`promoted to the rank of Associate Professor (initially without tenure) at Carnegie
`
`Mellon University in 1997, was promoted to tenured Associate Professor in 2002,
`
`and I was promoted to the rank of full Professor in 2008. I was the Associate
`
`Department Head for Faculty of the CS Department from 2009-2010.
`
`(4.) Since becoming a faculty member in 1993, I supervised the research
`
`of 11 Ph.D. dissertations in the field of computer science, and along with my
`
`graduate students, published over 60 technical publications in scientific journals or
`
`conferences in the field of computer science and 20 technical reports published at
`
`Carnegie Mellon University and the University of Toronto. In addition to Ph.D.
`
`dissertations, I have also supervised several graduate student’s Master’s theses.
`
`(5.) As part of my research, I have developed new techniques for
`
`efficiently keeping replicas of data up-to-date, similar to the goal of U.S. Patent
`
`No. 6,738,799 (“the ‘799 patent”). For example, in my S3 project, I published a
`
`number of papers in top research conferences on keeping replicated data up-to-date
`
`in a client-server environment distributed across the Internet. An exemplary list of
`
`publications relevant to this topic, which also highlight my familiarity with the
`
`concept of keeping replicated data up-to-date in a client-server environment (i.e.
`
`the underlying concept of the ‘799 patent) is provided below:
`
`a. Amit Manjhi, Charles Garrod, Bruce M. Maggs, Todd C. Mowry,
`Anthony Tomasic. Holistic Query Transformations for Dynamic Web
`
`
`
`‐ 2 ‐
`
`Oracle Exhibit 1008
`
`
`
`Applications. In Proceedings of the 2009 IEEE 25th International
`Conference on Data Engineering (ICDE), March-April 2009.
`
`b. Charles Garrod, Amit Manjhi, Anastasia Ailamaki, Bruce Maggs,
`Todd Mowry, Christopher Olston, and Anthony Tomasic. Scalable
`Query Result Caching for Web Applications. In Proceedings of the
`34th International Conference on Very Large Databases (VLDB),
`August 2008.
`
`c. Amit Manjhi, Phillip B. Gibbons, Anastassia Ailamaki, Charles
`Garrod, Bruce M. Maggs, Todd C. Mowry, Christopher Olston,
`Anthony Tomasic, and Haifeng Yu. Invalidation Clues for Database
`Scalability Services. In Proceedings of the 2007 IEEE 23rd
`International Conference on Data Engineering (ICDE), pages 316-
`325, April 2007.
`
`d. Amit Manjhi, Anastassia Ailamaki, Bruce M. Maggs, Todd C.
`Mowry, Christopher Olston, and Anthony Tomasic. Simultaneous
`Scalability and Security for Data-IntensiveWeb Applications. In
`Proceedings of the 2006 ACM SIGMOD International Conference on
`Management of Data, pages 241-252, June 2006.
`
`e. Christopher Olston, Amit Manjhi, Charles Garrod, Anastassia
`Ailamaki, Bruce M. Maggs, and Todd C. Mowry. A Scalability
`Service for Dynamic Web Applications. In Proceedings of the
`Second Biennial Conference on Innovative Data Systems Research
`(CIDR), pages 56-69, January 2005.
`
`(6.)
`
`I am a member of several professional organizations including the
`
`
`
`
`
`
`
`
`
`Institute of Electrical and Electronics Engineers (IEEE) and the Association of
`
`Computing Machinery (ACM). I am the incoming Editor-in-Chief of ACM
`
`Transactions on Computer Systems (TOCS). I received a Sloan Research
`
`Fellowship and the TR35 Award from MIT's Technology Review.
`
`
`
`‐ 3 ‐
`
`Oracle Exhibit 1008
`
`
`
`(7.)
`
`I have served as a consultant for Intel Corporation, Silicon Graphics,
`
`Inc., SandCraft, Inc., and IBM.
`
`(8.) A copy of my latest curriculum vitae (C.V.) is attached to this
`
`declaration as Appendix A.
`
`II. Description of the Relevant Field and the Relevant Timeframe
`
`
`(9.)
`
`I have carefully reviewed the ‘799 patent as well as the patents and
`
`applications referenced in the section of the ‘799 patent entitled “Related U.S.
`
`Application Data.”
`
`(10.) For convenience, all of the information that I considered in arriving at
`
`my opinions is listed in Appendix B. This includes Oracle’s first petition for inter
`
`partes review against the ‘799 patent (IPR2013-00073), including the declaration
`
`of Prof. Grimshaw submitted therewith, the Patent Owner’s preliminary response
`
`filed in that proceeding (Ex. 1009), and the Patent Office’s decision instituting
`
`inter partes review based on Oracle’s first petition (Ex. 1010).
`
`(11.) Based on my review of these materials, I believe that the relevant field
`
`for purposes of the ‘799 patent is basic distributing computing or file systems,
`
`particularly file synchronization in such systems. I have been informed that the
`
`relevant timeframe is on or before May 2, 1999.
`
`
`
`‐ 4 ‐
`
`Oracle Exhibit 1008
`
`
`
`(12.) As described in Section I above, I have extensive experience in
`
`computer science. Based on my experience, I have a good understanding of the
`
`relevant field in the relevant timeframe.
`
`III. The Person of Ordinary Skill in the Relevant Field in the Relevant
`Timeframe
`
`
`
`(13.) I have been informed that “a person of ordinary skill in the relevant
`
`field” is a hypothetical person to whom an expert in the relevant field could assign
`
`a routine task with reasonable confidence that the task would be successfully
`
`carried out. I have been informed that the level of skill in the art is evidenced by
`
`prior art references. The prior art discussed herein demonstrates that a person of
`
`ordinary skill in the field, at the time the ‘799 patent was effectively filed, was
`
`aware of server polling mechanisms and techniques for replicating or
`
`synchronizing files between two computers.
`
`(14.) Based on my experience, I have an understanding of the capabilities
`
`of a person of ordinary skill in the relevant field. I have supervised and directed
`
`many such persons over the course of my career. Further, I had those capabilities
`
`myself at the time the patent was filed.
`
`IV. The ‘799 Patent
`
`(15.) The ‘799 describes a way to synchronize files between two computers
`
`using an update file. According to the abstract of the patent, this is done by “[a]
`
`server generat[ing] an update file for transmission to a client that permits the client
`
`
`
`‐ 5 ‐
`
`Oracle Exhibit 1008
`
`
`
`to generate a copy of an earlier version of the subscription file.” (Ex. 1001 at
`
`Abstract). The disclosed process involves four simple steps.
`
`(16.) First, the client computer tells the server computer which files it
`
`would like the server to track for updates. (Id. at 7:50 – 8:6). Second, when the
`
`server detects that a monitored file has been updated, the server builds an update
`
`file to send to the client computer, which will allow the client computer to create a
`
`copy of the updated file. (Id. at 3:41-49). The update file is built by comparing a
`
`series of segments, or chunks of data, that define the overall contents and structure
`
`of each file (id. at 8:2-6) “to determine which segments have been altered, which
`
`ones are new and which ones have remained unchanged.” (Id. at 9:33-37). Based
`
`upon this comparison, the update file contains instructions for the client computer
`
`to generate the new version of the file by copying certain segments of the old file
`
`into the new file (i.e., for those segments of the old file that did not change and
`
`also appear in the new file) and inserting raw data for segments that have been
`
`altered or are new. (Id. at 11:60 – 12:13; Fig. 11). This procedure is also set forth
`
`in steps (a) – (c) of claims 12 and 30 of the ‘799 patent.
`
`(17.) Third, the update file is packaged into a self-extracting executable file
`
`that is emailed to the client. (Id. at 4:30-32; 11:52-57; 12:53-56). Lastly, the
`
`client updates its copy of the monitored file by executing the e-mailed update file.
`
`(Id. at 12:53-66).
`
`
`
`‐ 6 ‐
`
`Oracle Exhibit 1008
`
`
`
`(18.) While the bulk of the claims of the ‘799 patent, including presently
`
`challenged claims 12 and 30, recite the above-mentioned procedure with
`
`specificity, claim 42 of the ‘799 patent broadly describes a procedure where the
`
`server computer (1) determines if the client has the latest version of a monitored
`
`file; (2) generates an update, if the client does not have the latest version of a
`
`monitored file; and (3) transmits the update to the client computer. (Id. at claim
`
`42).
`
`V.
`
`Scientific Principles Underlying the ‘799 Patent
`
`(19.) As shown by the Balcha (Ex. 1003), Miller (Ex. 1004), and Williams
`
`(Ex. 1006) references discussed below and in the accompanying petition, there was
`
`nothing novel or unique about generating an update file (also referred to in the
`
`prior art as a “delta,” “diff,” or “difference file”) by 1999. In fact, the tools for
`
`building an update file would have been well-known and easily implemented by
`
`any computer scientist with an understanding of file systems and distributed
`
`computing. When designing a system to generate an update file, a skilled artisan,
`
`as a matter of design choice, would have employed one of two basic design
`
`methodologies – either a discard-by-default process (with a “copy” command) or a
`
`retain-by-default process (with a “delete” command). As described below, each
`
`methodology achieves the exact same result and, based upon the known duality
`
`between the methodologies, are indistinguishably different from one another.
`
`
`
`‐ 7 ‐
`
`Oracle Exhibit 1008
`
`
`
`(20.) In describing the discard-by-default and retain-by-default
`
`methodologies below, I refer to Fig. 9 of the ‘799 patent for ease of explanation
`
`and illustration. However, I must note that this figure discloses nothing new to a
`
`person of skill in the art and simply illustrates the prior art process for creating an
`
`update file. For example (and as will be discussed later) Fig. 18 of Williams
`
`illustrates the exact procedure described in Fig. 9 of the ‘799 patent.
`
`‘799 Patent Fig. 9
`
`Williams Fig. 18
`
`
`
`
`
`(21.) To efficiently create a new version of a file (e.g., “903” in Fig. 9 of
`
`the ‘799 patent) given that the content of a previous version of the file (e.g., “901”
`
`in Fig. 9 of the ‘799 patent) is available, there are fundamentally three types of
`
`content that must be identified: (i) new (or “changed”) chunks of data that are not
`
`in the previous version of the file (e.g., segments B2, B4, and B5 in “902” in Fig. 9
`
`of the ‘799 patent), (ii) chunks of data from the previous version of the file that are
`
`to be retained (e.g., segments A1, A3, A5, and A6 in “901” in Fig. 9 of the ‘799
`
`
`
`‐ 8 ‐
`
`Oracle Exhibit 1008
`
`
`
`patent), and (iii) chunks of data from the previous version of the file that are to be
`
`discarded (e.g., segments A2 and A4 in “901” in Fig. 9 of the ‘799 patent). The
`
`new file (“903”) is created by stitching together these new and retained chunks in
`
`the appropriate order, while skipping over the discarded chunks.
`
`(22.) Regarding the content of a delta/update file that is needed to capture
`
`how the new version of the file is to be created from the old version, the handling
`
`of new chunks (e.g., segments B2, B4, and B5 in “902” in Fig. 9) is fairly
`
`straightforward: since this data does not already exist in the previous version of the
`
`file (e.g., in “901” in Fig. 9), the full content of these new chunks must be included
`
`in the update file and inserted at the appropriate places in the new version of the
`
`file. Hence an “insert” command (for handling these new chunks) is common to
`
`each of the ‘799, Balcha (see, e.g., Ex. 1003 at 3:54-58), Miller (see, e.g., Ex. 1004
`
`at 5:56-60), and Williams (see, e.g., Ex. 1006 at 19:66 - 20:5; Fig. 18) patents.
`
`(23.) Regarding the chunks of data from the earlier version of the file that
`
`are to be retained and discarded, one possibility would be for the delta/update file
`
`to explicitly indicate for each chunk in the earlier version of the file whether it
`
`should be retained or discarded. In that case, the delta/update file would contain
`
`the following three commands: “insert” (for new segments, as discussed already),
`
`“copy” (i.e. retain a given chunk from the earlier file – e.g., segments A1, A3, A5,
`
`and A6 in “901” in Fig. 9 of the ‘799 patent), and “delete” (i.e. discard a given
`
`
`
`‐ 9 ‐
`
`Oracle Exhibit 1008
`
`
`
`chunk from the earlier file - e.g., segments A2 and A4 in “901” in Fig. 9 of the
`
`‘799 patent). However, one skilled in the art would quickly realize that a design
`
`with all three of these commands is overly pedantic (and inefficient) because it is
`
`not necessary to explicitly indicate both the chunks to retain and discard: explicitly
`
`specifying either one of these sets (i.e. all chunks to retain or all chunks to discard)
`
`will implicitly identify the other set. In other words, one can have either a retain-
`
`by-default policy where only the chunks to be discarded are specified (via a
`
`“delete” command) and all other chunks will be implicitly retained, or a discard-
`
`by-default policy where only the chunks to be retained must be specified (via a
`
`“copy” command) and all other chunks will be implicitly discarded. A person
`
`skilled in the art would have realized that the choice between either a retain-by-
`
`default or a discard-by-default policy is a simple engineering design choice.
`
`(24.) Accordingly, we observe both design choices in practice. The ‘799,
`
`Miller, and Williams patents chose a discard-by-default policy (where items to be
`
`retained are explicitly identified in the delta/update file), and the Balcha patent
`
`chose a retain-by-default policy (where items to be discarded are explicitly
`
`identified). In fact, as will be described in more detail below, the retain-by-default
`
`policy is explicitly shown in the Balcha patent in the definitions of the insertion,
`
`deletion, and modification primitives (Ex. 1003 at col. 7, lines 7-14), which each
`
`begin with “S[l, i]+”, designating that the next “i” bytes of the old file (i.e. stream
`
`
`
`‐ 10 ‐
`
`Oracle Exhibit 1008
`
`
`
`“S”) are to be copied to the new file (i.e. stream “S*”) if parameter “i” in the
`
`primitive is greater than zero.
`
`VI. Claim Interpretation
`
`(25.) In proceedings before the USPTO, I understand that the claims of an
`
`unexpired patent are to be given their broadest reasonable interpretation in view of
`
`the specification from the perspective of one skilled in the art. I have been
`
`informed that the ‘799 patent has not expired. In comparing the claims of the ‘799
`
`patent to the known prior art, I have carefully considered the ‘799 patent and the
`
`‘799 patent file history based upon my experience and knowledge in the relevant
`
`field. In my opinion, the claim terms of the ‘799 patent are used in their ordinary
`
`and customary sense as one skilled in the relevant field would understand them.
`
`(26.) In addition, it is my understanding that the Patent Office provided
`
`definitions for certain claim limitations as part of its Decision Instituting Inter
`
`Partes Review with respect to the first petition filed by Oracle against the ‘799
`
`patent. (See Ex. 1010 at 7-17). Thus, in conducting my analysis, I have utilized
`
`the following claim constructions, as set forth by the Board.
`
`Signature List = a collection (e.g., table) of representations of variable length
`segments of a subject file, which representations serve to identify the
`segments from which they are determined (e.g., a table of hashes).
`
`Update = information for updating a file or an up-to-date version of a file.
`
`Command to Copy = an instruction that causes the computer to duplicate
`information to data.
`
`
`
`‐ 11 ‐
`
`Oracle Exhibit 1008
`
`
`
`
`Command to Insert = an instruction that causes the computer to put or
`introduce certain information or data into another file.
`
`Determining whether the second computer has a latest version of a file and
`generating an update, if the second computer does not have a latest version
`of a file = this term does not require that the second computer have a latest
`version of the file prior to transmitting the update from the first computer to
`the second computer.
`
`Without Interaction = this term only limits the interaction between first and
`second computers as specifically recited in the claims.
`
`The Preambles – I have considered the preambles in conducting my analysis.
`
`VII. Discussion of Relevant Patents and Articles
`
`(27.) I have reviewed the relevant patents and articles listed in Appendix B,
`
`and based on this review, contributed to developing the claim charts comparing
`
`each element of claims 12, 30, and 42 of the ‘799 patent to the appropriate
`
`disclosures from the prior art references in the petition from the perspective of one
`
`skilled in the art.
`
`a. U.S. Patent No. 6,233,589 to Balcha (“Balcha”)
`
`(28.) As indicated by its title, U.S. Patent No. 6,233,589 to Balcha
`
`(“Balcha”) describes a “Method and System for Reflecting Differences Between
`
`Two Files” (called “base files” by Balcha), which are stored on separate servers.
`
`When a change is made to one of the base files, the server detecting the change
`
`generates a delta/update file, sends that delta/update file to the second server, and
`
`the second server uses the delta/update file to generate a copy of the updated file as
`
`
`
`‐ 12 ‐
`
`Oracle Exhibit 1008
`
`
`
`it exists at the first server. (Ex. 1003 at 4:51-67). The process described in the
`
`Balcha patent for synchronizing files between computers is indistinguishable from
`
`that described in the ‘799 patent. Moreover, as would have been readily
`
`recognized by a skilled artisan, the disclosed process for generating a delta/update
`
`file, which is generally illustrated in flow diagrams 4-6 of the patent, could be
`
`stored on and executed from computer readable storage medium. Similarly, Fig. 3
`
`of Balcha shows a backup server 30 in communication with a storage medium 34
`
`and computers 32. (Id. at 5:7-10). As would have been understood by a skilled
`
`artisan, the software executed by these machines, such as the software to
`
`implement the processes disclosed by Balcha, involves programs stored and
`
`executed from computer readable storage medium.
`
`(29.) Balcha’s first step, which directly corresponds to step (a) of claims 12
`
`and 30 of the ‘799 patent, compares a base signature file (representative of the
`
`content of the old file) to a revised signature file (representative of the content of
`
`the updated file) to identify matching blocks of data between the old file and the
`
`updated file. (Id. at 3:1-11; 3:21-36; 7:57-59, Fig. 5; 11:16-21). Next, as in step
`
`(b) of claims 12 and 30 of the ‘799 patent, Balcha generates a delta/update file that
`
`includes primitives instructing the second computer to preserve or copy into the
`
`current or updated version of the file all matching segments between the base
`
`signature file and the revised signature file. (Id. at 3:46-58). The copying or
`
`
`
`‐ 13 ‐
`
`Oracle Exhibit 1008
`
`
`
`preservation of matching blocks of data is an inherent mechanism of a retain-by-
`
`default system such as Balcha’s. This is also explicitly shown at col. 7, lines 6-14
`
`of Balcha, which provides the coding for the suggested “insertion,” “deletion,” and
`
`“modification,” primitives.
`
`
`
`In each primitive or command above, the first thing that goes into each output
`
`stream is “S[1, i]+…,” instructing the second computer to preserve or copy a given
`
`number of bytes at a given location. In other words, each primitive contains an
`
`explicit instruction specifying a portion of the original file that should be copied
`
`into the current version of the file before executing the remainder of the primitive,
`
`where “i” is the parameter that specifies how far ahead to copy. If “i” = 0, then no
`
`copying occurs. However, for any of the primitives, if “i” > 0, then the
`
`delta/update file instructs the second computer to copy the next “i” bytes into its
`
`copy of the current version of the file. In this way, each primitive of Balcha
`
`contains a copy command in the form of this parameter “i.”
`
`
`
`‐ 14 ‐
`
`Oracle Exhibit 1008
`
`
`
`(30.) The inherent copy command present in Balcha’s command primitives,
`
`which causes unchanged data segments to be retained or copied into the updated
`
`version of the file, is also depicted in the example at column 14.
`
`Ex. 1003 at 14:6-18
`
`
`Specifically, the first number following the parenthesis of each primitive tells the
`
`second computer how many data bytes to copy into its revised file copy before
`
`executing the stated primitive. For example, and as highlighted in blue above, the
`
`primitive “ins(5, 3, ‘XYZ’) instructs the second computer to copy the first five data
`
`bytes of the base file and then insert “XYZ.” Similarly, the primitive “ins(5, 6,
`
`‘PAABST’)” instructs the second computer to copy the next 5 data bytes into the
`
`revised file before inserting the 6 byte string PAABST, which is highlighted in
`
`green above.
`
`(31.) Further, as described in step (c) of claims 12 and 30 of the ‘799
`
`patent, Balcha provides for an insertion primitive instructing the second computer
`
`to include in its updated copy of the file all data segments that appeared in the
`
`
`
`‐ 15 ‐
`
`Oracle Exhibit 1008
`
`
`
`revised signature file but could not be found in the base signature file. (See, e.g.,
`
`id. at 3:46-58). This data is transmitted raw in the delta/update file, whereas the
`
`raw data for all retained or copied segments need not be included in the
`
`delta/update file as it is already held by the second computer in its copy of the
`
`earlier version of the file. (Id.; see also id. at 13:47 – 14:18).
`
`(32.) Lastly, because the first server stores a copy of the base signature file,
`
`it can generate a delta/update file for transmission to the second server “[u]pon
`
`detection of a modification to the [base] file,” and without interacting with the
`
`second server. (Id. at 4:52-67). Importantly, this change detection methodology is
`
`identical to that used by the ‘799 patent. In particular, when one of the servers
`
`described in Balcha detects a change to a base file, and because each server
`
`maintains identical file copies to the other, with respective base files, it is
`
`determined that the non-detecting server does not have the latest version of the file
`
`and the delta/update file generation process is initiated. In this same way, when
`
`the server described in the ‘799 notices that the time-stamp of a monitored
`
`document has changed, it assumes that interested clients have not independently
`
`obtained the latest version of the document and sends an update file to the client.
`
`(Ex. 1001 at 6:57-63).
`
`
`
`
`
`
`
`‐ 16 ‐
`
`Oracle Exhibit 1008
`
`
`
`b. U.S. Patent No. 5,832,520 to Miller (“Miller”)
`
`(33.) Miller describes an “Automatic File Differencing and Updating
`
`System” that utilizes a DIFF/update file transmitted between computers to create a
`
`copy of an updated file using the DIFF file and a duplicate of the old file. (Ex.
`
`1004 at 2:38-48). To generate the DIFF file, Miller utilizes a hash table to locate
`
`matching strings of data that exists in both the old file and the updated version of
`
`the file. (Id. at 5:48-50; 5:50-56; 6:39-51; 7:7-24; 8:25-29). Matching strings of
`
`data are to be retained when building a copy of the updated version of the file at
`
`the second computer and, thus, Miller describes that a copy command is placed
`
`into the DIFF/update file to convey this instruction. (See, e.g., id. at 5:52-56).
`
`Because the raw data for these segments already exists in the old file, it need not be
`
`included in the DIFF/update file. (See, e.g., id. at 8:23-31; 11:28-38). Next, for
`
`those strings of data that appear in the updated file but do not also appear in the old
`
`file, the DIFF/update file of Miller includes an insert command (along with the raw
`
`data to be inserted) instructing the second computer to include this new data in its
`
`copy of the updated file. (See, e.g., id. at 5:56-60). Further, the entire process of
`
`generating the DIFF/update file is carried out by the first computer, without the
`
`need to interact with the second computer that will ultimately receive and utilize
`
`the DIFF/update file. (See, e.g., id at 2:49-51; 15:26-38).
`
`
`
`
`
`‐ 17 ‐
`
`Oracle Exhibit 1008
`
`
`
`c. Balcha and Miller Combined
`
`(34.) I have been asked to consider whether a person of ordinary skill
`
`would have combined the Balcha and Miller patents. First, both patents describe
`
`processes and systems for achieving file synchronization or updating through the
`
`use of a delta, DIFF, or update file, all of which are synonymous to one another
`
`and produce the same end result: an old version of a file is updated to match the
`
`current version of that file (which is stored at a separate computer) by applying the
`
`update file to the now out-of-date file. This fact alone would naturally lead a
`
`person of ordinary skill in the art to combine the teachings of Balcha and Miller.
`
`Further, Miller describes that its invention addresses needed improvements to
`
`known delta file techniques utilized in distributing software updates. (See
`
`generally Ex. 1004 at Background of the Invention). As would have been
`
`understood by a skilled artisan, any delta file update technique for transmitting
`
`software updates could be predictably combined and utilized with file
`
`synchronization systems in general, such as that disclosed by Balcha.
`
`(35.) In the Patent Owner’s preliminary response, the Patent Owner argues
`
`that the combination of Balcha and Miller would result in a retain-by-default
`
`policy rather than a discard-by-default policy due to a desire to minimize the size
`
`of the difference file: “Here, the prior art cited in the Petition would drive the
`
`person of ordinary skill inexorably towards a solution that minimized the number
`
`
`
`‐ 18 ‐
`
`Oracle Exhibit 1008
`
`
`
`of bytes in a difference file. The combination of Balcha and Miller would, if
`
`anything, see the adoption of Balcha’s “no copy command” approach.” (Ex. 1009
`
`at 21). I disagree with this argument for several reasons, as did the Patent Office.
`
`(36.) First of all, the ‘799 patent itself correctly states what would have
`
`been ubiquitously well known to a person of ordinary skill in the art during the
`
`relevant time period – that the size of the copy commands is negligible compared
`
`with the size of the new data to be inserted: “In other words, the copy commands
`
`1101, 1103, 1106, and 1107 are negligible in size in comparison to the contents of
`
`the actual new or changed segments which must be transmitted.” (See Ex. 1001 at
`
`12:23-25). For example, the bulk of Miller’s disclosure relates to minimizing the
`
`size of a difference file by optimizing the use of “copy” commands versus “insert”
`
`commands. (See, e.g., Ex. 1004 at 3:17-38). The Patent Office also correctly
`
`recognized this and found that the usage of a copy command in Miller’s invention
`
`was an important feature allowing for the reduction of the number of bytes
`
`transmitted as part of a DIFF file and, as a result, that a person of ordinary skill
`
`would have not eliminated its usage as proposed by the Patent Owner. (Ex. 1010
`
`at 28-29).
`
`(37.) Second, the Patent Office correctly noted that a person of ordinary
`
`skill in the art would have been motivated to utilize a copy command, as in Miller,
`
`with the process set forth in Balcha to easily create a duplicate version of the
`
`
`
`‐ 19 ‐
`
`Oracle Exhibit 1008
`
`
`
`revised file at the second computer without eliminating the previous version. (Id.
`
`at 29). In this way, after the DIFF or update file is transmitted to the second
`
`computer and instantiated, the duplicate version of the revised file would be saved
`
`in a new location and, thus, both versions (the old version and the updated version)
`
`would exist at the second computer. As noted by the Patent Office, this would
`
`“ensure that the conversion is successful or other user applications are compatible
`
`with the revised file before deleting the previous version.” (Id. at 30).
`
`(38.) The desirability of saving both versions of the file at the second
`
`computer is also explicitly recognized by Balcha which, at col. 5, lines 4-39,
`
`discloses a backup server. In this example, it is clear that the updated file would be
`
`created as a separate file from the older version, since the goal is to have a backup
`
`system where “… any particular version of a file can be restored.” (Ex. 1003 at
`
`5:22-23). In order to restore any particular version of the file, at least the earliest
`
`version of the base file cannot be overwritten when a later instance is restored,
`
`since otherwise the ability to restore older backup versions would then be lost.
`
`Accordingly, saving the updated file to a separate location can be achieved using
`
`Balcha’s retain-by-default policy with “delete” command because, as described in
`
`paragraphs 19-24 and 29-30 above, a copy command is inherently built into each
`
`primitive disclosed by Balcha.
`
`
`
`‐ 20 ‐
`
`Oracle Exhibit 1008
`
`
`
`(39.) Lastly, and even perhaps most tellingly, a person of ordinary skill
`
`would have been motivated to use a “copy” command as taught by Miller because
`
`it simply represented one of the two primary tools in the skilled artisan’s arsenal
`
`for coding a “command to copy,” or “an instruction that causes the computer to
`
`duplicate information or data.” (Ex. 1010 at 11). Namely, as described above,
`
`these tools would be the discard-by-default policy (with “copy” command) or the
`
`retain-by-default policy (with “delete” command). Fundamentally, one needs to
`
`specify the boundaries where transitions occur between whether contiguous chunks
`
`of data should be retained or discarded. If contiguous chunks with the same state
`
`(retained or discarded) would be encoded with a single command, then the number
`
`of either “copy” or “delete” commands would be within one of each other (if the
`
`first and last chunks had opposite states, then the number of each command would
`
`be equal; if the first and last chunks had the same state, then there would be one
`
`more of that corresponding command).
`
`(40.) Another potential consideration is the typical size of one type of
`
`chunk versus the other. For example, if the bulk of the earlier version of the file is
`
`retained in the updated version, then the chunks of data to be retained may be
`
`much larger on average than the chunks to delete. This scenario might provide an
`
`advantage to the retain-by-default policy, with explicit “delete” commands, since it
`
`would require fewer bits to encode the size of a chunk to be deleted than a chunk to
`
`
`
`‐ 21 ‐
`
`Oracle Exhibit 1008
`
`
`
`be retained. However, the exact opposite could be true. If, for example, the bulk
`
`of the earlier version of the file is discarded in the updated version, then the chunks
`
`of data to be retained may be much smaller than the chunks to delete. This
`
`scenario might provide an advantage to the discard-by-default policy, with explicit
`
`“copy” commands, since it would require fewer bits to encode the size of a chunk
`
`to be retained than a chunk to be deleted. Hence I find no merit to the argument
`
`that someone who was concerned about minimizing the size of the difference file
`
`would be clearly mo
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
