`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`ORACLE CORPORATION
`
`Petitioner
`
`v.
`
`Patent of CLOUDING IP, LLC
`
`Patent Owner
`
`____________
`
`Case IPR2013-00073
`
`Patent 6,738,799
`
`____________
`
`
`
`DECLARATION OF WESLEY W. CHU, PH.D.
`
`
`
`I, WESLEY W. CHU, Ph.D. declare:
`
`1.
`
`I am currently a Distinguished Professor (emeritus) at the
`
`University of California, Los Angeles (UCLA) within the Computer
`
`Science Department and have been since 2009. I have worked at the
`
`Computer Science Department of UCLA since 1969 in the following
`
`positions: Professor (since 1975); Department Chair (1988-91),
`
`
`
`
`
`
`
`Distinguished Professor (since 1998), and Emeritus Distinguished
`
`Professor (sine 2009).
`
`2.
`
`For more than 47 years, I have worked in the field of
`
`computer science, with a particular focus on distributed processing,
`
`computer networks, real-time distributed processing systems and
`
`distributed databases for 31 years (1969-2000).
`
`3. My pioneering work in file allocation and directory design for
`
`distributed databases aided the design and development of domain
`
`name servers for the web and current cloud computing systems. I
`
`was elected as an IEEE Fellow for these accomplishments.
`
`4.
`
`I am the sole author of a seminal publication in the
`
`distributed data base field entitled Optimal File Allocation in a
`
`Multiple Computer System.1 Additionally, I am an author or co-
`
`1 W. W. Chu, Optimal File Allocation in a Multiple Computer
`
`author of more than 150 publications in the computer science field.
`
`System, IEEE Transactions on Computers, Vol. c-18, No. 10,
`
`October 1969, pp. 885-889.
`
`
`
`2
`
`
`
`
`
`I have been an editor of three textbooks on information technology
`
`and am a co-author of a reference book about data mining. Below is
`
`a list of my publications that are most relevant topics at issue in this
`
`Inter Partes Review:
`
`a. Articles:
`
`i. Chu, W. W., M. T. Lan and J. Hellerstein,
`
`"Estimation of Intermodule Communication (IMC)
`
`and Its Application in Distributed Processing
`
`Systems", IEEE Transactions on Computers,
`
`August 1984, pp.691-699.
`
`ii. Chu, W. W. and K. K. Leung, "Task Response
`
`Time Model and Its Applications for Real-Time
`
`Distributed Processing Systems", Proceedings of
`
`the Real Time Systems Symposium, December
`
`1984, pp. 225-236.
`
`iii. Chu, W. W. and J. Hellerstein, "The Exclusive-
`
`
`
`Writer Approach to Updating Replicated Files in
`
`3
`
`
`
`
`
`
`
`Distributed Processing Systems", IEEE
`
`Transactions on Computers, Vol. C-34, No. 6, pp.
`
`489-500, June 1985.
`
`iv. Jung Min An and Wesley W. Chu, “A Resilient
`
`Commit Protocol for Real Time Systems”
`
`Proceedings of the Real-time Systems Symposium,
`
`December 1985. pp. 25-29
`
`v. Wesley W. Chu and Jung M. An “ Fault tolerant
`
`Locking for Tightly Coupled Systems, Proceedings
`
`of the 5th Symposium on Reliability in
`
`Distributed Systems, Jan 13-15, 1986, Los Angeles,
`
`CA
`
`vi. Chu, W. W. and M. T. Lan, "Task Allocation and
`
`Precedence Relations for Distributed Real-Time
`
`Systems", IEEE Transactions on Computers, June
`
`1987, pp. 667-679.
`
`4
`
`
`
`
`
`
`
`vii. Chu, W. W. and K. K. Leung, "Module Replication
`
`and Assignment for Real-Time Distributed
`
`Processing Systems", Special Issue on Distributed
`
`Data Bases, IEEE Proceedings, May 1987, pp. 547-
`
`562.
`
`viii. Chu, W. W. and C. M. Sit, "A Batch Service
`
`Scheduling Algorithm with Time-Out for Real-
`
`Time Distributed Processing Systems", 7th
`
`International Conference on Distributed
`
`Computing Systems, September 1987.
`
`ix. Chu, W. W., C. M. Sit and K. K. Leung, "Task
`
`Response Time for Real-Time Distributed Systems
`
`with Resource Contentions", IEEE Transactions
`
`on Software Engineering, October 1991.
`
`x. Bagrodia, R., W. W. Chu, L. Kleinrock, and G.
`
`Popek, "Vision, Issues, and Architecture for
`
`5
`
`
`
`
`
`
`
`Nomadic Computing", IEEE Personal
`
`Communications, December 1995.
`
`xi. Chu, W. W., "Optimal File Allocation in Multiple
`
`Computer Systems", IEEE Transaction on
`
`Computers, October 1969, pp. 885-889.
`
`xii. Chu, W. W., "Performance of File Directory
`
`Systems for Data Bases in Star and Distributed
`
`Networks", AFIPS Conf. Proc., Volume 45, pps.
`
`577-587, June 1976.
`
`xiii. Chu, W. W. and P. Hurley, "Optimal Query
`
`Processing for Distributed Database Systems",
`
`IEEE Transactions on Computers, September
`
`1982, pp. 835-850.
`
`xiv. Chu, W. W. and I. T. Ieong, "A Transaction-Based
`
`Approach to Vertical Partitioning for Relational
`
`Database Systems", IEEE Transactions on
`
`Software Engineering, August 1993, pp. 804-812.
`
`6
`
`
`
`
`
`
`
`b. Books, Chapters in Books, Editorships:
`
`i. Jianming He and Wesley W. Chu. "Design
`
`Considerations for a Social Network Based
`
`Recommender System". Community-Built
`
`Databases: Research and Development, 2011
`
`ii. Jianming He and Wesley W. Chu. "Protecting
`
`Private Information in Online Social Networks"
`
`Chapter 14 in Intelligence and Security
`
`Informatics (edited by H. Chen and C.C. Yang),
`
`SCI 135, pp. 249-273, 2008.
`
`iii. Yu Chen and Wesley W. Chu. "Protection of
`
`Database Security via Collaborative Inference
`
`Detection" Chapter 15 in Intelligence and Security
`
`Informatics (edited by H. Chen and C.C. Yang),
`
`SCI 135, pp. 275-303, 2008.
`
`iv. Wesley W. Chu, Victor Liu, Wenlei Mao and
`
`Qinghua Zou "KMeX: A Knowledge-based Digital
`
`7
`
`
`
`
`
`5.
`
`
`
`Library or retrieving Scenario-specific Medical
`
`Text Documents" Chapter 14 in Biomedical
`
`Information Technology, (edited by D. Feng)
`
`Elsevier Academic Press Series in Biomedical
`
`Engineering, 2008.
`
`v. Wesley W. Chu and S. Liu. " Cooperative XML
`
`(CoXML) Query Answering". B. Wah, ed.
`
`Encyclopedia of Electrical and Electronic
`
`Engineering, John Wiley & Son, Inc., Dec. 2007.
`
`vi. Zou, Q., Y. Chen, W.W.Chu, X. Lu. "Mining
`
`Association Rules from Tabular Data Guided by
`
`Maximal Frequent Itemsets", in Foundations and
`
`Advances in Data Mining. Chu, W.W. and T.Y.
`
`Lin, eds. Springer, 2005.
`
`vii. Chu, W. W. and T.Y. Lin, Editors. Foundations
`
`and Advances in Data Mining." Springer, 2005.
`
`I am an inventor for seven US Patents:
`
`8
`
`
`
`
`
`
`
`a. “System and Methods for Evaluating Inferences for
`
`Unknown Attributes in a Social Network” U.S. Patent
`
`No. 8,160,993 April 17,2012, Lead inventor, Wesley W.
`
`Chu.
`
`b. “System and Method for Retrieving Scenario Specific
`
`Documents” U.S. Patent No. 7, 548,910, June 2009, Lead
`
`inventor, Wesley W. Chu.
`
`c. “Database Event Detection and Notification System
`
`Using Type Abstraction Hierarchy (TAH)” U.S. Patent
`
`No. 6,247,146, July 2002.
`
`d. “Database System with query relaxation using Type
`
`Abstraction Hierarchy (TAH) as Query Condition
`
`Relaxation Structure” U.S. Patent No. 6,427,146, Sept
`
`1999.
`
`e. “Statistical Multiplexing Systems for Computer
`
`Communications,” U.S. patent number 4,082,922, April
`
`1978; US Patent No. 4,093,823, June 1978.
`
`9
`
`
`
`
`
`f. “Multi-access Memory Module for Data Processing
`
`System,” (co-invented with P. Korff), U.S. Patent No.
`
`4,109,719, August 1978.
`
`g. “Multiplexed MOS Multi-accessed Memory System” (co-
`
`invented with D. Hibbits), U.S. Patent No. 4,415,991,
`
`November 1983.
`
`6.
`
`I have received numerous awards from the IEEE and was
`
`awarded a Life Fellowship in 2004.
`
`7.
`
`I earned my B.S. and M.S. in electrical engineering from the
`
`University of Michigan in 1960 and 1961, respectively and my Ph.D.
`
`in electrical engineering from Stanford University in 1966.
`
`8.
`
`A copy of my curriculum vitae, which details my experience
`
`that is relevant to these proceedings, is attached to this Declaration
`
`as Appendix A.
`
`9.
`
` I have read and understood U.S. Patent 6,739,799 (the ‘799
`
`patent) as well as Oracle Corporation’s Petition for Inter Partes
`
`Review and the exhibits cited therein, including Dr. Grimshaw’s
`
`
`
`10
`
`
`
`
`
`Declaration, the Patent Owner’s Preliminary Response, the Patent
`
`Trial and Appeal Board’s Decision Instituting the Inter Partes
`
`Review proceeding, and the transcript of Dr. Grimshaw’s
`
`deposition, taken May 29, 2013.
`
`
`
`I. State of the Art at the Time of the ‘799 Patent.
`
`10.
`
`In 1996, Trigdale and Mackerras reported on the rsync
`
`algorithm; a mechanism for updating a file on one computer to be
`
`identical to a file on another computer. Andrew Trigdale and Paul
`
`Mackerras, “The rsync algorithm”, The Australian National
`
`University Joint Computer Science Technical Report Series, TR-
`
`CS-95-05 (June 1996) (Appendix A-6 to Oracle Ex. 1007). To
`
`accommodate low-bandwidth communication links connecting the
`
`two computers, rsync identified portions of the file that were the
`
`same on each computer and exchanged only differences
`
`therebetween. Id. at p. 1. To identify the differences between the
`
`files, rsync requires a receiving computer to send a transmitting
`
`
`
`11
`
`
`
`
`
`computer, representations of blocks of the version of the file stored
`
`by the receiving computer. The transmitting computer compares
`
`these representations to representations of blocks of the file stored
`
`by the transmitting computer. Based on these comparisons, the
`
`transmitting computer sends the receiving computer those blocks of
`
`its file that did not have matching blocks in the receiving
`
`computer’s version of the file along with information for how to
`
`merge those blocks into the receiving computer’s version of the file.
`
`Id. at p. 2. For blocks where the transmitting computer did find a
`
`match in the receiving computer’s version of the file, the
`
`transmitting computer sends references to those blocks to the
`
`receiving computer. Id. The receiving computer uses its version of
`
`the file along with the references to matching blocks, raw missing
`
`blocks, and instructions for merging the raw missing blocks sent by
`
`the transmitting computer to updates its copy of the file. Id. at pp.
`
`1-2.
`
`
`
`
`
`II. Overview of U.S. Patent 6,738,799.
`
`12
`
`
`
`
`
`11. U.S. Patent 6,738,799 (the “’799 Patent”) (Oracle Ex. 1001)
`
`describes systems and methods for generating update files that
`
`permit a computer to generate a current version of a file from a copy
`
`of an earlier version thereof. Ex. 1001 at Abstract; 3:45-49. To
`
`facilitate this process, files are segmented and each segment is
`
`represented by a signature. Id. at 8:7 et seq. Signatures are
`
`representations of variable length segments of a subject file, which
`
`representations serve to identify the segments from which they are
`
`determined. Id. at Fig. 4; 8:18-20, 29-54. One example of a signature
`
`list provided in the ‘799 Patent is a table of hashes. Id. at col. 8:20-
`
`28.
`
`12. The process taught in the ‘799 Patent makes use of the
`
`signatures to determine whether a file has been modified. By
`
`comparing an earlier version of a signature list (representing an
`
`earlier version of a subject file) to a signature list that corresponds
`
`to a current version of the file, differences between the current and
`
`former versions of the file can be readily determined. See, e.g., id. at
`
`col. 10:5-14. Based on these differences, an update file is
`
`
`
`13
`
`
`
`
`
`constructed. Id. at col. 10:66 – 11:50. The update file includes
`
`instructions (e.g., copy, insert) for a
`
`recipient computer to construct the current
`
`version of the subject file from its earlier
`
`copy thereof and data included in the
`
`update file. Id. and see Fig. 11. Once
`
`created, the update file can be provided to the recipient computer,
`
`for example via email. Id. at 11:51-52.
`
`13. Unlike the rsync algorithm, the process described and claimed
`
`in the ‘799 Patent allows one computer to determine whether a
`
`second computer has a latest version of a file and, if not, to generate
`
`an update file without interaction with the second computer. See,
`
`e.g., Id. at 18:32-39.
`
`
`
`III. Materials and information Provided To Me.
`
`14.
`
`I am advised that in proceedings before the USPTO, the
`
`claims of an unexpired patent are to be given their broadest
`
`
`
`14
`
`
`
`
`
`reasonable interpretation in view of the specification from the
`
`perspective of one of ordinary skill in the art. I have been informed
`
`that the ’799 Patent has not expired. Therefore, in comparing the
`
`claims of the ’799 Patent to the cited references, I have given the
`
`claims their broadest reasonable interpretation in view of the
`
`specification from the perspective of one of ordinary skill in the art.
`
`15.
`
`I have been informed that “a person of ordinary skill in the
`
`art” 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 may be evidenced by references published at
`
`or around the time of the filing of the patent under consideration.
`
`In performing my analysis I have applied the level of ordinary skill
`
`in the art based upon such information as well as my experience
`
`and knowledge in the relevant field.
`
`16. Based on my experience, I have an understanding of the
`
`capabilities of a person of ordinary skill in the relevant art. I have
`
`supervised and directed many such persons over the course of my
`
`
`
`15
`
`
`
`
`
`career. Further, I had those capabilities myself at the time the
`
`patent was filed.
`
`17.
`
`I am informed that the ‘799 Patent was filed on June 2, 2003,
`
`as a continuation of Application No. 09/303,958, filed May 3, 1999.
`
`Thus a reference qualifies as prior art only if it disclosed or
`
`suggested the claimed invention of the ‘799 Patent prior to May 3,
`
`1999.
`
`18.
`
`I am advised that claims may be found unpatentable as
`
`anticipated if a single prior art reference discloses each limitation of
`
`the claim, either expressly or inherently. I understand a limitation to
`
`be inherently disclosed only if it is necessarily present in the
`
`reference.
`
`19.
`
`I am advised that a patent claim can be found unpatentable as
`
`obvious where the differences between the subject matter of the
`
`claim and the prior art are such that the subject matter as a whole
`
`would have been obvious at the time the invention was made to a
`
`person having ordinary skill in the art. I understand that an
`
`
`
`16
`
`
`
`
`
`obviousness analysis involves a consideration of (1) the scope and
`
`content of the prior art; (2) the differences between the claimed
`
`invention and the prior art; (3) the level of ordinary skill in the
`
`pertinent field; and (4) secondary considerations of obviousness.
`
`
`
`
`
`IV. Discussion of the Cited References.
`
`1. The Combination of Balcha and Miller with Regard to Claims 1
`
`and 23.
`
`20.
`
`I have been asked to consider U.S. Patent 6,233,589, to Balcha
`
`et al. (“Balcha”) (Oracle Ex. 1003), and whether a person of ordinary
`
`skill in the art would combine the teachings of Balcha with those of
`
`U.S. Patent 5,832,520 to Miller (“Miller”) (Oracle Ex. 1004) to arrive
`
`at the subject matter recited in Claims 1 and 23 of the ‘799 Patent.
`
`21. Balcha relates generally to the backup and synchronization of
`
`files, and in particular relates to a method and system for reflecting
`
`
`
`17
`
`
`
`
`
`differences between two files (a base file and a revised file). Ex. 1003
`
`at 1:5-7. The differences between the two files are reflected in a
`
`delta file and the delta file is created based on a comparison of a
`
`base signature file (which represents the base file), a revised
`
`signature file (which represents the revised file) and the revised file
`
`itself. Id. at 7:46 – 8:6.
`
`22. Balcha provides examples of a base file, a base signature file, a
`
`revised file, a revised signature file and a resulting delta file. One
`
`such example, taken from col. 13, ll. 50 et seq., is reproduced below.
`
`In this example, “the periods used to delineate certain characters
`
`are not part of the file itself, and are used merely to illustrate certain
`
`logical distinctions between groups of characters”. Id. at 13:40-42.
`
`
`
`
`
`18
`
`
`
`
`
`23. According to Balcha, the delta file incudes certain
`
`“primitives,” which can be used to generate a copy of the revised file
`
`from the delta file. As explained by Dr. Grimshaw in his deposition,
`
`primitives are generally understood as the simplest elements
`
`available in a programming language. Ex. 2002 at 38:14 – 39:15.
`
`Specifically, Balcha uses primitives for “insert”, “modify” and
`
`“delete”. Id. at 3: 55-56. The operation of these primitives is
`
`explained, with reference to the above example, at col. 14, ll. 5-19:2
`
`
`
`
`2 In this exposition, the “⌃” character indicates the position of a
`
`19
`
`pointer in the base file at which the corresponding primitive is
`
`applied. Ex. 1003. at 13:65 – 14:1.
`
`
`
`
`
`24. According to Balcha, the above example shows how the delta
`
`file requires that the base file
`
`(ABCDE.FGHIJ.KLMNO.PQRST.UVWXY.Z) be first modified by
`
`inserting, at a position 5 characters from the initial pointer position,
`
`a 3-character string, “XYZ”. Next, beginning at the then-current
`
`pointer position, a 5-character string is deleted. Thereafter, and
`
`beginning at a location 5 characters from the then-current pointer
`
`position, a 6-character string, “PAABST” is inserted. Finally, the
`
`pointer position is advanced 5 characters and a 5-charater string is
`
`deleted. In this way, a new version of the old file is created wherein
`
`new data is added to the old version of the file via the “insert”
`
`primitive, undesired data is deleted from the old version of the file
`
`via the “delete” primitive, and data within the old version of the file
`
`is modified via the “modify” primitive. Id. at 14:5-19.
`
`25. Thus, in the Balcha process, data within the old version of the
`
`file that is not modified or deleted remains in the new version of the
`
`file with no need to copy that information from the old version of
`
`the file to the new version of the file. Consequently, Balcha has no
`
`
`
`20
`
`
`
`
`
`need for and does not write a copy “primitive” (or any other
`
`instruction) into the delta file to effect the copying of data from the
`
`old version of the file into the new version of the file. Predictably
`
`then, Balcha neither teaches nor suggests writing such a command
`
`or other instruction for duplication into the delta file.
`
`26. Dr. Grimshaw reads the above-described example from Balcha
`
`as calling for “commands embedded in the delta file [to] cause the
`
`unchanged bits to be effectively copied into the revised file.”3 This
`
`is incorrect. Balcha does not “effectively copy” over any bits from an
`
`old version of a file to a revised version of the file. Instead, as shown
`
`quite clearly in the example discussed above, the old file is
`
`converted to the revised file directly through execution of the insert
`
`and delete instructions included in the delta file. No copying (or
`
`effective copying) or other duplication of this kind is performed or
`
`required because the revised version of the file is itself directly
`
`produced from the old version of the file and the difference file and
`
`
`
`
`3 Ex. 1007 at ¶ 25, emphasis added.
`
`
`
`21
`
`
`
`
`
`anything not deleted from, or modified within, the old version of
`
`the file remains in the revised version of the file. Ex. 1003 at 13:64 –
`
`65. Dr. Grimshaw acknowledged this in his deposition by noting
`
`that,
`
`Balcha is an instance of the retained data by
`
`default. Therefore, if you want something to
`
`exist in the new file that existed in the old
`
`file, there’s no need to explicitly say copy that
`
`stuff over because it’s going to be retained by
`
`default.
`
`Ex. 2002 at 43:17-22.
`
`27. Furthermore, and applying the Board’s construction of the
`
`term “command to copy,” Claims 1 and 23 require that in the event
`
`of a match between “an old segment signature” and “a new segment
`
`signature”, an instruction that causes the second computer to
`
`duplicate the second computer’s copy of the old segment of the file
`
`into the second computer’s copy of the current version of the file be
`
`
`
`22
`
`
`
`
`
`written into the update. Insofar as “transitory copies” of files or
`
`portions thereof may be ephemerally created in one or more
`
`memories of a computer system during the operations described by
`
`Dr. Grimshaw (e.g., regarding copies of files that may be
`
`temporarily resident in volatile memory), such creation is not
`
`equivalent to or a result of writing a “command to copy” (or other
`
`instruction that causes the computer to duplicate information or
`
`data) that is written in the Balcha delta file. It is merely the
`
`mechanism by which a computer processor is required to operate
`
`on data. Stated differently, Balcha does not describe writing a
`
`command to copy or its equivalent into an update file nor is the
`
`writing of such a command to the update file inherent in Balcha.
`
`28. Miller relates to a system for creating, updating or revising
`
`large computer files. Ex. 1004 at 7:12-15. More specifically, Miller
`
`describes a procedure for revising large computer files using
`
`“difference files” or DIFF files – i.e., files containing indications of
`
`the differences between the large computer files and a preexisting
`
`
`
`23
`
`
`
`
`
`computer file. Id. at 1:10-15. An
`
`overview of that process is illustrated in
`
`Miller’s Figure 1, shown here.
`
`29. Miller’s DIFF file includes
`
`primitives for “copy”, “insert” and
`
`“insert/copy” operations, which impart
`
`directives for handling strings that
`
`appear in new and old copies of the subject file. Id. at Fig. 5A.
`
`Miller describes a distinct preference for the DIFF file indicating
`
`changes between the old file and the new file to include a minimum
`
`number bytes so that the DIFF file is the smallest such file possible.
`
`Id. at 2:21-24, 31-33. Failing to use a file that was as small as
`
`possible would defeat Miller’s very objective.
`
`30. Oracle’s Petition alleges that, “[a] skilled artisan would have
`
`recognized that Miller’s commentary about what was generally
`
`known in the art concerning use of delta files to update software
`
`would be fully applicable to and predictably combined with Balcha’s
`
`
`
`24
`
`
`
`
`
`method for updating delta files.” Petition at p. 17. I disagree with
`
`this allegation for three reasons.
`
`31. First, according to Balcha, a revised version of a file is created
`
`by inserting new data into the old version of the file as well as
`
`modifying and deleting information included within the old version
`
`of the file. Any data within the old version of the file that is not
`
`deleted or modified remains within the revised version. Therefore,
`
`it is not necessary to copy any information from the old version of
`
`the file into the revised version and, consequently, a skilled artisan
`
`would not be motivated to add a “copy” primitive to Balcha’s
`
`methods for updating files at least because the information to be
`
`copied is already included within the updated version.
`
`32. Second, there is no logical rational for a skilled artisan to add
`
`the “copy” primitive of Miller to the process of Balcha because
`
`execution of the “copy” primitive within the process of Balcha
`
`would require the coping of data into the updated file that was
`
`already included within the file, thereby causing redundant data to
`
`be added to the updated version of the file. Additionally, such
`
`
`
`25
`
`
`
`
`
`redundancy would necessarily increase the memory and processing
`
`costs associated with the storage and processing of the revised file, a
`
`concept inapposite to both Balcha and Miller.
`
`33. Third, by avoiding the use of a copy command, Balcha
`
`necessarily reduces the number of bytes needed to convey
`
`information in the delta file for the updating of the file. Hence, a
`
`skilled artisan would not be motivated to add the “copy” primitive of
`
`Miller to the teachings of Balcha because doing so would increase
`
`the amount of data included within the delta file and, as a result,
`
`increase the memory, processing, and file transmission costs for the
`
`delta file of Balcha with, as demonstrated above, no practical
`
`benefit.
`
`
`
`
`
`
`
`2. Balcha with Regard to Claim 37
`
`
`
`26
`
`
`
`
`
`34.
`
`I have been asked to consider the Balcha patent and its
`
`relevance to claim 37 of the ‘799 Patent.
`
`35. Balcha discloses sharing changes between two base files
`
`wherein a change to a first version on the base file indicates that a
`
`second version of the same base file is now not the same as the first
`
`version of the case file. Ex. 1003 at 4:52-67.
`
`36. As explained by Balcha with reference to Figure 1, provided
`
`
`
`above:
`
`
`
`Each of servers 22 and 24 maintain a copy of
`
`a base file 21, 27, respectively and are
`
`interconnected via a network 26. Base files
`
`21, 27 should be identical to one another
`
`and thus changes made to one copy should
`
`27
`
`
`
`
`
`eventually be reflected in the other copy. A
`
`base signature file, as described in more
`
`detail herein, is generated on one of the
`
`servers 22, 24 and copied to the other server.
`
`The base signature file is maintained on
`
`server 22 as file 20, and maintained on server
`
`24 as file 28. Either base file 21 or 27 can be
`
`modified at either server.
`
`Upon detection of a modification to the file,
`
`the detecting server, for example server 22,
`
`uses the respective base signature file, for
`
`example, base signature file 20, to generate a
`
`new delta file, and communicates the delta
`
`file over network 26 to server 24. Server 24
`
`then uses the delta file to update the base file
`
`27, and recalculates the base signature file
`
`28.
`
`Id. at 4:52-67, emphasis added.
`
`
`
`28
`
`
`
`
`
`37. Thus, when a modification of base file 21 is detected by server
`
`22, server 22 generates a new delta file and communicates that delta
`
`file to server 24, which then proceeds to modify base file 27 using
`
`the delta file. However, the detection of the modification of base file
`
`21 is in no way related to a determination that base file 21 is the
`
`latest version of the base file. Instead, Balcha only discloses
`
`detecting whether a base file has been modified, regardless of when
`
`that modification may have occurred relative to other copies of the
`
`same base file.
`
`38. To illustrate the significance of this difference, consider the
`
`following situation (which builds upon the scenario provided by
`
`Balcha reproduced above) in which base file 27 has been modified
`
`more recently than base file 21 and, as a consequence, base file 27 is
`
`the latest version of the file. If a modification of base file 21 is
`
`detected, Balcha will perform the updating of base file 27 to be
`
`consistent with base file 21 even though base file 27 is the latest
`
`version of the file. In such a circumstance, the “updating” of Balcha
`
`will serve to inappropriately overwrite the modifications made to
`
`
`
`29
`
`
`
`
`
`base file 27 and adversely modify the latest version of the base file
`
`(i.e., base file 27) to an older version of the base file (i.e., base file
`
`21). Such a circumstance is all the more likely in Balcha because
`
`“[b]ase files 21, 27 should be identical to one another and thus
`
`changes made to one copy should eventually be reflected in the
`
`other copy.” Id. at 4:54-56, emphasis added. Thus, there is a lag in
`
`the updating of base file 27 to be consistent with base file 21.
`
`39. Furthermore, the probability of an inappropriate file update
`
`occurring when using Balcha’s file synchronization approach is
`
`magnified when the number of base files within the system
`
`increases beyond two copies of the same base file, as it is even more
`
`likely that multiple versions of the base file will be updated within
`
`the “eventual” time frame and when those changes are detected in
`
`their respective versions by their respective servers, delta files will
`
`be created and then used to modify all of the other versions of the
`
`base file within the system. This will rapidly create an
`
`unsustainable situation where there is no master version of the base
`
`file steering the updating/synchronizing of the base files, thereby
`
`
`
`30
`
`
`
`
`
`introducing inefficiency and errors into the file synchronization of
`
`Balcha. These problems are only magnified as the system scales.
`
`40. The method of claim 37 avoids this problem by determining
`
`whether the second computer has a latest version of a file and, in
`
`this way, establishes that the latest version of the file will not be
`
`overwritten by changes to a file that occurred previously to the
`
`changes of the latest version of the base file.
`
`
`
`
`
`
`
`3. Williams with Regard to Claims 1, 23, and 24.
`
`41.
`
`I have been asked to consider U.S. Patent 5,990,810 to
`
`Williams (“Williams”) (Oracle Ex. 1006), and its relevance to Claims
`
`1, 23 and 24 of the ‘799 Patent.
`
`42. Williams describes a fine-grained incremental backup system
`
`that includes two entities, (e.g., two computers on a network) E1 and
`
`
`
`31
`
`
`
`
`
`E2, that wish to repeatedly backup a file, X, as modified and stored
`
`on E1. “Each time E1 performs a backup operation, it partitions X
`
`into subblocks and writes the hashes of the subblocks to a shadow
`
`file S. Ex. 1006 at 19:35-37. When X is modified, the hash S will
`
`only correspond to the previously saved version of X, which
`
`Williams refers to as “Y.”
`
`43. According to Williams,
`
`To perform the backup, E1 compares the
`
`hash of Y (stored in S) against the hash of X
`
`to see if X has changed. If X hasn’t changed,
`
`there is no need to perform any further
`
`backup action. If X has changed, E1
`
`partitions X into subblocks, and compares
`
`the hashes of these subblocks with the
`
`hashes in the shadow file S, so as to find all
`
`identical hashes. Identical hashes identify
`
`identical subblocks in Y that can be
`
`transmitted [to E2] by reference. E1 then
`
`32
`
`
`
`
`
`
`
`transmits the [incremental backup D] file as a
`
`mixture of raw subblocks and references to
`
`subblocks whose hashes appear in S and
`
`which are therefore known to appear as
`
`subblocks in Y.
`
`Id. at 19:44-55.
`
`44. Then, “[t]o reconstruct X from Y and D [ ], E2 partitions Y
`
`into subblocks [and] calculates the hashes of the subblocks . . . . [E2]
`
`then processes the incremental backup information [D by] copying
`
`subblocks that were transmitted raw and looking up the references
`
`either in Y or in the part of X already reconstructed. Id. at 19:66-
`
`20:5.
`
`45. Thus, Williams teaches the construction of incremental
`
`backup information of X that includes raw subblocks, which
`
`represents data not included in the previously saved version of X
`
`(i.e., Y) and references to subblocks that are included in Y. Absent
`
`from this incremental backup information is any command to copy
`
`
`
`33
`
`
`
`
`
`(or it equivalent) a segment of Y into X as reconstructed at E2.
`
`Instead, all that is included in the incremental backup information
`
`is a reference to a segment of Y to be retained, by E2, when
`
`reconstructing X. However, neither this reference, nor the
`
`incremental backup information, includes any command, or
`
`instruction, to copy or duplicate the related segment of Y when
`
`reconstructing X at E2.
`
`46. During his deposition, Dr. Grimshaw agreed that there is no
`
`explicit command to copy that is written into the backup D. Ex. 2002
`
`at 15:16 – 16:21. However, Dr. Grimshaw maintained that such an
`
`instruction would be implied by the encoding of the D file. Id. I
`
`disagree with this assessment. Williams is concerned with an
`
`incremental backup system in which Y is updated to become a copy
`
`of X. Ex. 1006 at 19:31-33. Therefore, it is my view that any encoding
`
`in the D file would not be to “copy” segments from an old version of
`
`Y to a new
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
