IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`PATENT TRIAL & APPEAL BOARD
`
`Peter Dickinson
`6,738,799
`May 18, 2004
`10/452,156
`June 2, 2003
`Methods and Apparatuses for File Synchronization and
`Updating Using a Signature List
`
`DECLARATION OF DR. ANDREW GRIMSHAW, PH.D.
`
`
`
`In re Patent of:
`U.S. Patent No.:
`Issue Date:
`Appl. No.:
`Filing Date:
`Title:
`
`I, Dr. Andrew Grimshaw, Ph.D., declare as follows:
`
`(1.)
`
`I am currently a Professor of Computer Science at the University of Virginia’s
`
`School of Engineering and Applied Science and Chief Architect for the NCSA-led eXtrem
`
`Science and Engineering Discovery Environment (XSEDE) project. XSEDE is the cornerstone
`
`of the National Science Foundation’s cyber-infrastructure program for science and engineering
`
`in the United States.
`
`(2.)
`
`For more than 30 years, I have studied, designed, and worked in the field of
`
`computer science and engineering. My experience includes more than 25 years of teaching and
`
`research, with research interests in distributed systems including client-server and peer-2-peer
`
`interaction, grid computing, high-performance parallel computing, compilers for parallel
`
`systems, and operating systems, just to name a few.
`
`(3.)
`
`I received a Bachelor of Arts degree in Political Science and Economics from the
`
`University of California, San Diego in 1981, a Master of Science degree in Computer Science
`
`from the University of Illinois at Urbana-Champaign in 1986, and a Doctor of Philosophy degree
`
`in Computer Science from the University of Illinois at Urbana-Champaign in 1988.
`
`
`
`SAP Exhibit 1009, Page 1 of 36
`
`

`
`
`
`(4.) Over the last three decades, I have architected, developed, and released to
`
`customers five large distributed systems: two in industry (Open Access at SPI and the Avaki
`
`Data Grid at Avaki), two in academia (Mentat and Gensis II), and one that spanned both
`
`environments (Legion).
`
`(5.)
`
`In 1999 I co-founded Avaki Corporation, which offered enterprise level grid
`
`computing software solutions. I served as Avaki’s Chairman and Chief Technical Officer until
`
`2005 when Avaki was acquired by Sybase.
`
`(6.)
`
`I am a member of the Global Grid Forum (GGF) Steering Committing and the
`
`Architecture Area Director of the GGF. I have also served on the National Partnership for
`
`Advanced Computational Infrastructure (NPACI) Executive Committee, the DoD MSRC
`
`Programming Environments and Training (PET) Executive Committee, the Center of Excellence
`
`in Space Data and Information Sciences (CESDIS) Science Council, the National Research
`
`Counsel (NRC) Review Panel for Information Technology, and the Board on Assessment of
`
`National Institute of Standards and Technology (NIST) Programs.
`
`(7.)
`
`I have served on the Editorship and Program Committees for over 35 scientific
`
`conferences and symposiums covering the fields of distributed computing, parallel computing,
`
`grid-based computing, and supercomputing. I have also served on over 20 professional panels
`
`and working groups in the same fields for the National Science Foundation (NSF), National
`
`Aeronautics and Space Administration (NASA), and the NRC, among others.
`
`(8.)
`
`I have presented as a panelist in over 30 conferences throughout the United States
`
`and across the globe regarding grid computing, parallel computing, and distributed computing.
`
`(9.)
`
`I am the author or co-author of over 50 publications and book chapters in the field
`
`of distributed computing, and over 65 articles from conference proceedings and standards
`
`
`
`2
`
`SAP Exhibit 1009, Page 2 of 36
`
`

`
`
`
`documents. Many of these publications describe distributed computing systems, some of which
`
`are directed specifically to client-server interaction and replication. These publications highlight
`
`my familiarity with client-server file synchronization. Below is a list of my publications that are
`
`particularly relevant to the above topics:
`
` Nguyen-Tuong and A.S. Grimshaw, “Using Reflection for Incorporating Fault-
`Tolerance Techniques into Distributed Applications,” Parallel Processing Letters,
`vol. 9, No. 2 (1999), 291-301.
`
` Michael J. Lewis, Adam J. Ferrari, Marty A. Humphrey, John F. Karpovich, Mark M.
`Morgan, Anand Natrajan, Anh Nguyen-Tuong, Glenn S. Wasson and Andrew S.
`Grimshaw, “Support for Extensibility and Site Autonomy in the Legion Grid System
`Object Model” Journal of Parallel and Distributed Computing, Volume 63, pp. 525-
`38, 2003.
`
` A.S. Grimshaw, A. Natrajan, “Legion: Lessons Learned Building a Grid Operating
`System”, Proceedings of the IEEE, vol. 93, number 3, March, 2005, pp. 589-603.
`
` S. Grimshaw, Mark Morgan, Karolina Sarnowska, “WS-Naming: Location
`Migration, Replication, and Failure Transparency Support for Web Services,”
`Concurrency and Computation: Practice and Experience, vol. 21, issue 8, pp. 1013-
`1028.
`
` Sal Valente and Andrew Grimshaw, Replicated Grid Resources, Grid 2011: 12th
`IEEE/ACM International Conference on Grid Computing, September, 2011, Lyon,
`France.
`
` K. Sarnowska, A. Grimshaw, E. Laure. “Using Standards-based Interfaces to Share
`Data across Grid Infrastructures,” 38th International Conference on Parallel
`Processing (ICPP09), Page(s):254 – 260, Vienna, AU, Sept. 22-25, 2009.
`
` Sosa, C. and A.S. Grimshaw, Bringing the Grid home, in Proceedings of the 2008 9th
`IEEE/ACM International Conference on Grid Computing. 2008, IEEE Computer
`Society.
`
` H. Huang, and A. S. Grimshaw, “The Cost of Transparency: Grid-Based File Access
`on the Avaki Data Grid,” International Symposium on Parallel and Distributed
`Processing and Applications 2006, pp. 642-659, LNCS 4330, December 3-6 2006,
`Sorrento, Italy.
`
` White, M. Walker, M. Humphrey, and A. Grimshaw “LegionFS: A Secure and
`Scalable File System Supporting Cross-Domain High-Performance Applications”,
`Proceedings SC 01, Denver, CO.
`www.sc2001.org/papers/pap.pap324.pdf
`
`
`
`3
`
`SAP Exhibit 1009, Page 3 of 36
`
`

`
`
`
` J.F. Karpovich, A.S. Grimshaw, and J. C. French, “Extensible File Systems (ELFS):
`An Object-Oriented Approach to High Performance File I/O,” Proceedings of
`OOPSLA ‘94, Portland, OR, Oct 1994: 191-204.
`
` A.S. Grimshaw and E.C. Loyot Jr., “ELFS: Object- Oriented Extensible File
`Systems,” Proceedings 1991 Parallel and Distributed Information Systems
`Conference, Miami, FL, Dec 1991: 510-513.
`
` A.S. Grimshaw and J. Prem, “High Performance Parallel File Objects,’’ Proceedings
`of the Sixth Distributed Memory Computing Conference, Portland, OR, April 1991:
`720-723.
`
`(10.) A copy of my curriculum vitae, which describes in further detail my
`
`qualifications, responsibilities, employment history, honors, awards, professional associations,
`
`invited presentations, and publications is attached to this declaration as Appendix A-1.
`
`(11.)
`
`I have reviewed United States Patent No. 6,739,7991 (“the ‘799 patent”) to Peter
`
`Dickinson as well as the patents and applications referenced in the section of the ‘799 patent
`
`entitled “Related U.S. Application Data.” I have also reviewed the publications cited in the
`
`footnotes of this declaration and referenced in the inter partes review petition submitted
`
`herewith. Additionally, I have reviewed the petitions and related documents in IPR2012-00073,
`
`IPR2013-00261 and IPR2013-00586. I note that I maintain my previous opinions provided in
`
`IPR2012-00073 and IPR2013-00261, and agree with the Petitioners’ other experts in those
`
`proceedings and share many of the same opinions below. Because my independent analysis of
`
`the claims and prior art led to the same conclusions as the previous experts, I have incorporated
`
`many of their arguments and characterizations below as my own.
`
`STATE OF THE ART AS OF 1999
`
`(12.) From the 1970s until the present day, a substantial body of research has reported
`
`on the advent and subsequent advancement in distributed computing systems. In its simplest
`
`
`1 Dickinson, P., “Methods and Apparatuses for File Synchronization and Updating Using a
`Signature List.” U.S. Patent No. 6,738,799, filed June 2, 2003, claiming priority to May 3, 1999.
`
`
`
`4
`
`SAP Exhibit 1009, Page 4 of 36
`
`

`
`
`
`form, a distributed system is a collection of stand-alone computing machines (servers, client-
`
`PCs, etc.) that are connected through a network, such as the internet or a corporate intranet. One
`
`area of distributed system research which is of particular relevance to the ‘799 patent is
`
`commonly referred to as event-based notification.
`
`(13.) Generalized in the 1990s, event-based notification systems utilized a
`
`publish/subscribe mechanism to push notifications from a publisher to a subscriber regarding a
`
`specified event. In a publish/subscribe system, clients subscribe to events in which they are
`
`interested and, when that event occurs, the publisher (a server) notifies the subscribers with a
`
`notification message2. The notification message lets subscribers know that the event occurred
`
`and may also contain arbitrary data, such as a document of interest that triggered the event
`
`notification.3 For instance, by 1995, Stanford University had developed the SIFT system which
`
`automatically disseminated text documents (specifically, news articles) that matched the profile
`
`of a subscribed client.4 By 1996, the publish/subscribe push methodology was in widespread use
`
`and being used to automatically deliver web content (such as news headlines, weather forecasts,
`
`etc.) to subscribed clients.5 The methodology was also being used during this time period to
`
`transparently deliver software updates to subscribed clients.
`
`(14.) Developing in parallel to these advancements was a body of research regarding
`
`efficient mechanisms for synchronizing copies of files. The concept of constructing delta files
`
`2 Franklin, M. et al., “A Framework for Scalable Dissemination-Based System,” Proceedings of
`the 12th ACM SIGPLAN Conference on Object-oriented Programming, Systems, Languages, and
`Applications, 94-105, 96-97 (1997). (See A-3).
`3 Id. at 101-102, § 4.3.
`4 Id.; see also Yan, T.W., et al., “SIFT – A Tool for Wide-Area Information Dissemination,”
`Proceedings of the USENIX 1995 Technical Conference, 176-186 (1995). (See A-4).
`5 Franklin, M., et al., “Data In Your Face:” Push Technology in Perspective,” SIGMOD ‘98
`Proceedings of the 1998 ACM SIGMOD International Conference on Management of Data, 516-
`519, 516 (June 1-4, 1998). (See A-5).
`
`
`
`5
`
`SAP Exhibit 1009, Page 5 of 36
`
`

`
`
`
`was introduced into Unix in 1974 via the diff command that creates a set of differences between
`
`two text files (later versions supported binary files).6 The output of diff could then be used with
`
`the Unix patch command to update an old file by applying the generated differences to the out-of-
`
`date file.
`
`(15.) The Unix diff tool was often used to construct delta files for synchronizing files
`
`saved at multiple locations across a network. For example, a master copy of a file may be
`
`located at a server (“computer A”), and a replica of the file may be saved at a client PC
`
`(“computer B”). When the master copy is updated, it does not make sense to transfer the entire
`
`new file to computer B. Rather, to conserve network resources, an efficient system would only
`
`transfer the differences between the new file and the old file to computer B.
`
`(16.) To address the efficiency issue, the “rsync algorithm” was developed by Andrew
`
`Tridgell and Paul Mackerras in 1996.7 The heart of the algorithm is the means to identify parts
`
`of the old and new files that are identical to one another and only transmit raw data for those
`
`parts of the new file that did not previously exist in the old file. Following the scenario
`
`described above involving computers A and B, the rsync protocol operates as follows. Computer
`
`A and computer B at some point each have a copy of the same version of a file. At some later
`
`point, the file is updated on computer A, and the system must then update the same file on
`
`computer B. First, computer B is instructed to split its copy of the old file into a series of
`
`
`6 See, e.g., Hunt, J.W., et al., “An algorithm for differential file comparison,” Bell Laboratories
`Computing Science Technical Report #41, Abstract (July 1976) (describing the diff algorithm
`which “reports differences between two files, expressed as a minimal list of line changes to bring
`either file into agreement with the other”). (See A-6).
`7 Tridgell, A., et al., “The rsync algorithm,” The Australian National University Joint Computer
`Science Technical Report Series, TR-CS-95-05, 1-6 (June 1996). (See A-7).
`
`
`
`6
`
`SAP Exhibit 1009, Page 6 of 36
`
`

`
`
`
`segments and to generate a table of checksums and location offsets for each segment.8
`
`Checksums are simply unique identifiers (or signatures) generated for each segment of the file
`
`and used to compare segments of data to determine if the segment has changed. A change in the
`
`checksum related to a specific segment of data (otherwise known as a “signature mis-match”)
`
`indicates that the segment has changed in some way between file versions. Next, computer B
`
`transmits the generated checksums and offsets relating to computer B’s version of the file to
`
`computer A, which computer A then uses to search for any segment in the new file that matches
`
`the checksum for a segment in the old file.9 Once the comparison process is complete, computer
`
`A generates an update file that is a sequence of copy or insert commands.10 A copy command
`
`refers to a segment that existed in the old file and an insert command comprises new data for
`
`which there was no corresponding segment in the old version of the file. Lastly, computer A
`
`sends the update file to computer B, which allows computer B to generate a copy of the new file
`
`using the transmitted update file and its copy of the old file.11 Rsync rapidly became part of the
`
`Unix/Linux culture and was widely used in the computer science field.
`
`(17.) Further, by February 1999 at the latest, Tridgell had recognized rsync’s
`
`applicability to incremental backup systems.12 In this scenario, the entire rsync procedure used to
`
`generate an update file is carried out by a single computer, without the need for a second
`
`
`8 Id. at 2.
`9 Id.
`10 Id.
`11 Id.
`12 Tridgell, A., “Efficient Algorithms for Sorting and Synchronization,” Doctoral Dissertation
`Presented at the Australian National University, 92 (Feb. 1999). (See A-8).
`
`
`
`7
`
`SAP Exhibit 1009, Page 7 of 36
`
`

`
`
`
`computer to initially send checksums for a reference file, as discussed above.13 Rather, the
`
`backup system stores the signature list associated with the last transmitted backup and compares
`
`this list to the current version of the file to generate a new delta file, which corresponds to all file
`
`changes carried out since the last backup procedure.14 In this manner, the backup system
`
`operates as a subscription server, maintaining a list of all updates transmitted to a backup
`
`medium and initiating the rsync algorithm after a given file has been updated since a previous
`
`transmission.
`
`(18.) An earlier patent to Cane et al. (“Cane”)15, describes an incremental backup system
`
`as envisioned by Tridgell. In Cane, a “changed block file” is transmitted from a first computer to a
`
`backup system (such as a tape drive) and includes raw data only for those segments of the file which
`
`have been added or modified since a previous backup procedure.16 Changed file segments are
`
`identified by comparing a signature list for the current version of the file with a signature list
`
`representative of the file prior to the last backup procedure.17 The “changed block file” can later
`
`be used to create a copy of the most current version of the file by replacing all blocks of data in
`
`the original file for which there is a corresponding block, as identified by location offset
`
`information, in the changed block file.18
`
`
`13 Id. at 92-93 (stating “that the backup system does not need to read the old file from tape [or a
`second computer] in order to compute the differences”).
`14 Id.
`15 Cane, D., et al., “High Performance Backup via Selective File Saving Which Can Perform
`Incremental Backups and Exclude Files and Uses a Changed Block Signature List,” U.S. Patent
`No. 5,765,173, filed January 11, 1996 and issued June 9, 1998. (See A-9).
`16 Id. at 1:50-56.
`17 Id. at 4:7-17.
`18 Id. at 4:40-57.
`
`
`
`8
`
`SAP Exhibit 1009, Page 8 of 36
`
`

`
`
`
`(19.) The “final frontier” for the push methodology (at least according to the patentee)
`
`was “electronic document delivery.19” Electronic document delivery simply entails generating
`
`and transmitting a difference-based update file “that permits the client computer to generate a
`
`copy of a current version of a subscription file from a copy of an earlier version of the
`
`subscription file.20” As shown by the discussion of relevant patents and articles below, the
`
`technique proposed by the patentee represents nothing more than a straightforward document
`
`push implementation of the systems described by Tridgell and Cane, which was pursued and
`
`accomplished by many before the Patent Owner.
`
`THE ‘799 PATENT
`
`(20.) The ‘799 patent describes a method for synchronizing files between a server and
`
`client computer using a publish/subscribe push methodology. The patent describes a “mobile
`
`update server” that tracks files for changes and, when a change is detected to a monitored file,
`
`the server pushes an update via e-mail to all interested clients.21 Interested clients are those that
`
`the server has determined do not have the latest version of the monitored file. The update pushed
`
`from the server to the client is a delta or update file, which contains copy commands for blocks
`
`of the file that have not changed and raw data for those portions of the file that have been
`
`modified or created since the last synchronization between server and client.22 The client uses
`
`the delta file, along with the previous version of the monitored file saved at the client, to
`
`construct a copy of the new version of the file.23
`
`
`19 ‘799 patent at 2:56-63. (Ex. 1001)
`20 Id. at 3:47-49.
`21 Id. at 7:50-60.
`22 Id. at 3:58 - 4:22.
`23 Id. at 3:45-49.
`
`
`
`9
`
`SAP Exhibit 1009, Page 9 of 36
`
`

`
`
`
`(21.) The update file is generated using a standard differencing algorithm that compares
`
`a signature list for the most current version of the monitored file with an old signature list
`
`corresponding to the version of the file last transmitted to the client computer.24 The signature list
`
`is nothing more than a listing of unique identifiers, generated using known hashing or signature
`
`algorithm techniques25, which correspond to each segment of the file. The file is broken into n
`
`number of segments to promote efficient file comparison. For example, if a 50 page document
`
`was only broken into 5 segments, then a change to one paragraph on the second page of the
`
`document would require 1/5 of the document to be transmitted as raw data in the update file.
`
`However, if that same document was broken into 100 or 1,000 segments, the granularity of the
`
`comparison is substantially finer and requires substantially less raw data to be transmitted in the
`
`update.
`
`Scientific Principles Underlying the ‘799 Patent
`
`(22.) 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,
`
`24 Id. at 11:3-8.
`25 Id. at 8:18-28.
`
`
`
`10
`
`SAP Exhibit 1009, Page 10 of 36
`
`

`
`
`
`based upon the known duality between the methodologies, are indistinguishably different from
`
`one another.
`
`(23.)
`
`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
`
`(24.) 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
`
`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
`
`
`
`11
`
`SAP Exhibit 1009, Page 11 of 36
`
`

`
`
`
`by stitching together these new and retained chunks in the appropriate order, while skipping over
`
`the discarded chunks.
`
`(25.) 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.
`
`(26.) 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 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-
`
`
`
`12
`
`SAP Exhibit 1009, Page 12 of 36
`
`

`
`
`
`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.
`
`(27.) 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 “S”) are to be
`
`copied to the new file (i.e., stream “S*”) if parameter “i” in the primitive is greater than zero.
`
`CLAIM INTERPRETATION
`
`(28.)
`
`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 field. 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.
`
`(29.)
`
`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. 1008 at 7-17). Thus, in
`
`
`
`13
`
`SAP Exhibit 1009, Page 13 of 36
`
`

`
`
`
`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 or data.
`
`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 as being limitations in
`conducting my analysis.
`
`DISCUSSION OF RELEVANT PRIOR ART
`
`(30.) As an initial matter, the Petition challenges claims 1, 5-10, 12, 16-21, 23, 24, 30,
`
`31, 37, and 42. I note that claims 1, 5-10, 23, 24, and 37 are method claims and claims 12, 16-
`
`21, 30, 31, and 42 are computer readable storage claims, which are identical to the method
`
`claims except for the recitation of “computer readable storage medium” and “computer readable
`
`program code” in the claim preambles. Below, I discuss the Williams, Miller, Balcha and
`
`Freivald patents and discuss how each of these patents either individually or in various
`
`combinations discloses the methods of the method claims. The patents disclose those methods
`
`through computers utilizing computer readable program code residing in computer readable
`
`
`
`14
`
`SAP Exhibit 1009, Page 14 of 36
`
`

`
`
`
`storage mediums—such as memory, secondary storage, and the like. This would be readily
`
`apparent to one of ordinary skill in the art.
`
`The Combination of Balcha and Miller
`
`(31.)
`
`I have been asked to consider the Balcha et al. patent (“Balcha”)26 and Miller
`
`patent (“Miller”)27, and whether a person of ordinary skill in the field would be inclined to
`
`combine the techniques of Balcha and Miller.
`
`(32.) Balcha describes a mechanism for synchronizing files on two different computers
`
`using an update or delta file. In order to best understand the mechanism of Balcha, reference to
`
`Fig. 1 of the patent is appropriate.
`
`Servers 22 and 24 each store base files 21 and 27, which are initially identical to one another.28
`
`Files 20 and 28 represent base signature files for base files 21 and 27, respectively.29 The base
`
`
`
`
`26 Balcha, M., et al., “Method and System for Reflecting Differences Between Two Files,” U.S.
`Patent No. 6,233,589, filed July 31, 1998 and issued May 15, 2001. (Ex. 1003).
`27 Miller, W.A., “Automatic File Differencing and Updating System,” U.S. Patent No.
`5,832,520, filed Nov. 22, 1996 and issued Nov. 3, 1998. (Ex. 1004).
`28 Ex. 1003 at 4:51-56.
`29 Id. at 4:56-60.
`
`
`
`15
`
`SAP Exhibit 1009, Page 15 of 36
`
`

`
`
`
`signature files 20 and 28 comprise a “plurality of bit patterns,” which are CRC patterns30, for
`
`each n number of segments created for base files 21 and 27.31
`
`(33.) As a brief aside, it is worth noting that the prior art patents relied upon in the
`
`petition and described herein variously use the terms “hash,” “checksum,” or cyclic-redundancy-
`
`check (“CRC”) (sometimes also MD4 or MD5) to describe the specific type of signature used
`
`during the file comparison process underlying each patent. Although each procedure may vary
`
`slightly in technical implementation, which is beyond the scope of the ‘799 patent, they each
`
`represent a specific technique which falls under the general umbrella of signatures known to a
`
`person of ordinary skill in the field. Moreover, the file comparison procedure claimed in the
`
`‘799 patent may be implemented using “any one of a variety of hashing methods or signature
`
`algorithms” and, therefore, each procedure described in the prior art is compatible with the
`
`procedure described and claimed in the ‘799 patent.32
`
`(34.) Continuing with the description of Balcha from above, at some later point in time,
`
`base file 21, for example, may be updated. Once updated, a new base signature file is created,
`
`compared to base signature file 20, and based upon the comparison, a delta file is created
`
`reflecting the differences between the base file and the revised file.33 The comparison process
`
`described by Balcha directly corresponds, and is indistinguishably different from, the signature
`
`list search process (for example, at step (a) of claim 1) described in the ‘799 patent. The
`
`generated delta file is then transmitted over communication link 26 to server 24 where a copy of
`
`
`30 Id. at 8:19-24.
`31 Id. at 7:46-49.
`32 Ex. 1001 at 8:18-28.
`33 Ex. 1003 at 3:7-11; see also 7:65 – 8:6.
`
`
`
`16
`
`SAP Exhibit 1009, Page 16 of 36
`
`

`
`
`
`the revised file can be created using base file 27 and the delta file.34 In accordance with common
`
`practice, the delta file of Balcha includes raw data only for those segments of the revised base
`
`file that do not match a segment of the base file, and excludes raw data for matching segments
`
`between the files.35 Because base files 21 and 27 were initially maintained in a consistent state
`
`and should remain identical to one another, a change to either file indicates to the detecting
`
`server that the disclosed differencing process must be initiated.36 Moreover, because the
`
`detecting server stores a local copy of the base signature file, it can generate the disclosed delta
`
`file without interaction with the receiving server.37 I also note that in the example shown at
`
`column 14 of Balcha the non-zero offsets on the delete and insert comm