throbber

`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`UNIFIED PATENTS, INC.
`SAP AMERICA INC.
`Petitioners
`v.
`CLOUDING IP, LLC
`Patent Owner
`____________
`Case IPR2013-000586
`Case IPR2014-00306
`Patent 6,738,799
`____________
`
`
`
`
`PATENT OWNER’S RESPONSE TO
`PETITIONS FOR INTER PARTES REVIEW OF
`U.S. PATENT NO. 6,738,799
`UNDER 35 USC §§ 316 AND 37 CFR §42.120
`
`
`
`
`
`
`
`

`

`Table of Contents
`1. Introduction ................................................................................................ 1
`
`2. Overview of U.S. Patent 6,738,799 ............................................................. 2
`
`3. Argument ..................................................................................................... 4
`
`A. Claims 37 and 42 Are Not Anticipated by Balcha. ................................. 4
`
`B. Claims 1, 5, 9, 10, 12, 16, 20, 21, 23, 24, 30, and 31 Are Patentable
`
`Over Balcha When Considered In Combination with Miller. ...................... 9
`
`C. Claims 6-8 and 17-19 are Patentable Over Balcha Even When
`
`Considered in Combination with Miller and Freivald. ............................... 22
`
`D. Claims 37 and 42 are Patentable Over Balcha When Considered in
`
`Combination with Freivald. ....................................................................... 24
`
`E. Claims 1, 12, 23, 24, 30, and 31 are Not Anticipated by Williams
`
`Because Williams Fails to Teach Writing in an Update a Command to Copy
`
`or a Command to Insert, as Required by the Claims. .................................. 26
`
`F. Claims 5-10 and 16-21 are Patentable in View of Williams When
`
`Considered in Combination with Miller. .................................................... 34
`
`G. Claims 37 and 42 are Not Anticipated by Williams. ............................ 37
`
`5. Conclusion ................................................................................................ 39
`
`
`
`
`
`  
`
`
`
`ii  
`
`

`

`
`
`Cases
`
`Table of Authorities
`
`Bayer Schering Pharm. AG v. Barr Labs., Inc.,
`575 F.3d 1341 (Fed. Cir. 2009) (Newman, J., dissenting) ......................... 17
`
`Ex parte Levy, 17 USPQ2d 1461 (Bd. Pat. App. & Inter. 1990) .................... 33
`
`In re Fine, 837 F.2d 1071 (Fed. Cir. 1988) .................................................... 37
`
`KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398 (2007) ............................. 10, 17, 35
`
`Net MoneyIN, Inc. v. VeriSign, Inc., 545 F.3d 1359 (Fed. Cir. 2008) ......... 9, 34
`
`Richardson v. Suzuki Motor Co., 868 F.2d 1226 (Fed. Cir. 1989) ..................... 8
`
`Verdegaal Bros. v. Union Oil Co. of California,
`814 F.2d 628 (Fed. Cir. 1987) ................................................................... 38
`
`W.L. Gore & Associates, Inc. v. Garlock, Inc.,
`721 F.2d 1540 (Fed. Cir. 1983), cert. denied, 469 U.S. 851 (1984) ...... 19, 36
`
`
`
`
`Regulations
`
`37 C.F.R. § 42.107(c) ...................................................................................... 1
`
`
`
`Other Authorities
`
`MPEP § 2112 ................................................................................................ 32
`
`MPEP § 2142 ................................................................................................ 21
`
`
`
`  
`
`
`
`iii  
`
`

`

`
`2001
`
`
`2002
`
`
`2003
`
`
`2004
`
`
`2005
`
`
`2006
`
`2007
`
`2008
`
`
`2009
`
`2010
`
`2011
`
`
`
`
`
`  
`
`EXHIBIT LIST
`
`Decker, Susan, “Google, NetApp Sidestep Courts to Combat
`Patent Claims,” Bloomberg L.P., Oct. 13, 2013.
`
`Proof of Service on Google Inc., Stec IP v. Google Inc., civil action
`no. 12-cv-00639 (D. Del.).
`
`Unified Patents, Inc., “Unified Patents Challenges Clouding IP
`Patent Seeks to Push Patent Trolls Out of Cloud Storage,”
`September 17, 2013.
`
`Inter Partes Reexamination Proceeding Control No. 95/001,045,
`Decision Vacating Filing Date, p. 7-8, August 25, 2008.
`
`Unified Patents, Inc., “The Gloves Are Off: Unified Patents Inc.
`Unveils Its ‘NPE Deterrent’ Strategy.”
`
`Excerpt from File Wrapper of U.S. Application 10/452,156.
`
`Excerpt from File Wrapper of U.S. Application 09/303,958.
`
`Brin, Sergey et al., “Copy Detection Mechanisms for Digital
`Documents,” ACM International Conference on Management of
`Data (SIGMOD 1995), May 22-25, 1995, San Jose, California.
`
`Declaration of Prasant Mohapatra, Ph.D.
`
`Curriculum Vitae of Prasant Mohapatra, Ph.D.
`
`Transcript of Deposition of Norman Hutchinson, Ph.D., May 2,
`2014.
`
`iv  
`
`

`

`Pursuant to 37 C.F.R. § 42.120, the Board’s Scheduling Order of March
`
`21, 2014, and the Order concerning Joinder with IPR2014-00306 dated May
`
`20, 2014, Patent Owner, Clouding IP, LLC, submits the following response to
`
`the Petitions filed by Unified Patents, Inc. and SAP America Inc. Submitted
`
`concurrently herewith is Patent Owner’s Continent Motion to Amend claim 42
`
`under 37 C.F.R. § 42.121.
`
`1. Introduction
`
`
`
`Trial was instituted with respect to Claims 1, 5-10, 12, 16-21, 23, 24,
`
`30, 37 and 42 of U.S. Patent 6,738,799 (the “’799 Patent”) (Ex. 1001). At the
`
`outset, it is noted that all the Board has determined to date is that there is a
`
`“reasonable likelihood” that Petitioners will prevail as to some grounds for
`
`which Petitioners sought review, and it should be remembered that this
`
`determination was made in the absence of any rebuttal testimony provided by
`
`the Patent Owner.1 The Board has not determined any claims of the ‘799
`
`Patent to be unpatentable.
`
`As demonstrated below, the Board should enter judgment in favor of the
`
`                                                                                                                
`
`1 Patent Owners are prohibited from introducing rebuttal testimony prior to
`
`institution of inter partes review proceedings. 37 C.F.R. § 42.107(c).
`
`  
`
`1  
`
`

`

`Patent Owner because
`
`a. Claims 1, 12, 23, 24, 30, 31, 37, and 42 are not anticipated under 35
`
`U.S.C. § 102(e) by Williams, U.S. Patent 5,990,810 (Ex. 1006);
`
`b. Claims 5-10 and 16-21 are not obvious under 35 U.S.C. § 103(a) in
`
`view of Williams and Miller, U.S. Patent 5,832,520 (Ex. 1004);
`
`c. Claim 37 and 42 are not anticipated under 35 U.S.C. § 102(e) by
`
`Balcha, U.S. Patent 6,233,589 (Ex. 1003);
`
`d. Claims 1, 5, 9, 10, 12, 16, 20, 21, 23, 24, 30, and 31 are not obvious
`
`under 35 U.S.C. § 103(a) in view of Balch and Miller;
`
`e. Claims 6-8 and 17-19 are not obvious under 35 U.S.C. § 103(a) in
`
`view of Balcha, Miller and Freivald, U.S. Patent 5,898,836 (Ex.
`
`1005); and
`
`f. Claims 37 and 42 are not obvious under 35 U.S.C. § 103(a) in view
`
`of Balcha and Freivald.
`
`
`
`2. Overview of U.S. Patent 6,738,799.
`
`
`
`The ‘799 Patent 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; col. 3, ll. 45-49. To facilitate
`
`  
`
`2  
`
`

`

`this process, files are segmented and each segment is represented by a signature.
`
`Id. at col. 8, ll. 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; col.
`
`8, ll. 18-20, 29-54. Differences between a current
`
`version of a file and an earlier version thereof are
`
`determined using these signatures. See, e.g., Id. at
`
`10:5-14. Based on these differences, an update file
`
`is 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 version thereof
`
`and data included in the update file. Id. and see Fig. 11 (reproduced here).
`
`Once created, the update file is provided to the recipient computer, for example
`
`via email. Id. at 11:51-52.
`
`
`
`Importantly, for purposes of the present proceedings, one of the
`
`instructions included in the update file is a “command . . . to copy an old
`
`segment of the [receiving] computer’s copy of the earlier version of the file into
`
`the [receiving] computer’s copy of the current version of the file.” Id. at Claim
`
`1, 14:53-57; Claim 23, 16:61-65. Examples of such commands are illustrated
`
`  
`
`3  
`
`

`

`in Fig. 11, supra. Therefore, steps (b) in Claims 1, 12, 23, and 30 are properly
`
`understood as reciting the requirement of writing in the update, an instruction
`
`that causes the second computer to duplicate information or data from an old
`
`segment of the second computer’s copy of the earlier version of the file into the
`
`second computer’s copy of the current version of the file, wherein the old
`
`segment corresponds to the segment for which a match was detected in step (a).
`
`Ex. 2009 at ¶ 13.
`
`
`
`3. Argument
`
`A. Claims 37 and 42 Are Not Anticipated by Balcha.
`
`Claims 37 and 42 recite “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 the file.”2 Ex 1001 at 18:32-37 and 18:56-19:7.
`
`                                                                                                                
`2  In construing this term the Board incorrectly concluded that the claims “do
`
`not require that the second computer has a copy of the file.” Decision,
`
`Institution of Inter Partes Review, Paper 9 at 13. As explained in Patent
`
`Owner’s Preliminary response, the plain meaning of this limitation, and the
`
`one that the Board should adopt when construing the claim, is that the second
`
`  
`
`4  
`
`

`

`Balcha fails to teach such features, Ex. 2009 at ¶ 14, and, therefore, Balcha
`
`cannot anticipate Claims 37 and 42.
`
`Balcha discloses sharing changes between two base files wherein a change
`
`to a first version of the base file indicates that a second version of the same base
`
`file is now not the same as the first version of the base file. Ex. 1003 at 4:52-67.
`
`                                                                                                                                                                                                                                                                                                                                          
`
`computer must currently possess some version of the file. Indeed, the literature
`
`
`
`recognizes that where the subject of “updates” is concerned (Claims 37 and 42
`
`being directed to methods for providing such updates), it is inherent that “an
`
`old version of the file already exist[s] at the other end of the link.” Ex. 1016 at
`
`p. 59. By articulating a process that requires a first computer to determine
`
`whether a second computer has a copy of a file (i.e., a latest version of that file),
`
`claims 37 and 42 necessarily implies that the second computer must already
`
`possess some version of the file. Ex. 1001 at col. 1, ll. 24-27.
`
`
`
`  
`
`5  
`
`

`

`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 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).
`
`Based on this disclosure of Balcha, the Board concluded, “[f]rom the
`
`point of view of the computer generating the delta file, the system has
`
`  
`
`6  
`
`

`

`determined that the base file is not ‘a latest version’ of the file.” Decision,
`
`Institution of Inter Partes Review, Paper 9 at 23. This conclusion is incorrect as
`
`Balcha only discloses detecting a modification to the file without regard to
`
`whether the modified file is, indeed, the latest version of the file. Ex. 2009 at ¶
`
`16. 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. Id. However, the
`
`detection of the modification of base file 21 is in no way related to, or
`
`dependent upon, a determination that base file 21 is the latest version of the
`
`base file. Id. 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. Id.
`
`Dr. Mohapatra explains the significance of this difference is
`
`demonstrated by considering situations 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. Id. at ¶ 17. 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. Id. In such a
`
`circumstance, the “updating” of Balcha will serve to inappropriately overwrite
`
`  
`
`7  
`
`

`

`the modifications made to 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). Id. 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. citing Ex. 1003 at
`
`4:54-56 (emphasis added). The method and computer readable program code
`
`of claims 37 and 42, respectively avoids problems such as the inappropriate file
`
`updating described by Dr. Mohapatra 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 simply because the
`
`files are not the same (i.e., one of the files has been modified). Id.
`
`To anticipate a claim, “The identical invention must be shown in as
`
`complete detail as is contained in the … claim.” Richardson v. Suzuki Motor
`
`Co., 868 F.2d 1226, 1236 (Fed. Cir. 1989). Here, Balcha fails to meet this
`
`requirement. Stated differently, Balcha fails to disclose “within the four corners
`
`of the document not only all of the limitations claimed but also all of the
`
`limitations arranged or combined in the same way as recited in the claim,
`
`[hence] it cannot be said to prove prior invention of the thing claimed and,
`
`  
`
`8  
`
`

`

`thus, cannot anticipate under 35 U.S.C. § 102.” Net MoneyIN, Inc. v. VeriSign,
`
`Inc., 545 F.3d 1359, 1371 (Fed. Cir. 2008).
`
`Additionally, neither the Petition nor Dr. Hutchinson’s declaration
`
`demonstrate that Balcha teaches all of the elements of claims 37 and 42 in the
`
`manner in which those elements are arranged in the claim. Instead, Dr.
`
`Hutchinson states only that, “[b]ecause [Balcha indicates] 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.” Ex. 1007 at ¶ 34. Claims 37
`
`and 42, however, require “determining whether a second computer has a latest
`
`version of a file.” The forgoing comments by Dr. Hutchinson fail to
`
`demonstrate how Balcha teaches this feature.
`
`Hence, for at least these reasons, Balcha fails to disclose all of the features
`
`of claims 37 and 42 and, consequently, cannot anticipate claims 37 and 42.
`
`
`
`B. Claims 1, 5, 9, 10, 12, 16, 20, 21, 23, 24, 30, and 31
`Are Patentable Over Balcha When Considered In
`Combination with Miller.
`
`The key to supporting any rejection under Section 103 is the clear
`
`articulation of the reasons why the claimed invention would have been obvious.
`
`  
`
`9  
`
`

`

`KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398 (2007). Even if a person of ordinary
`
`skill in the art were to combine the teachings of Balcha and Miller, the resulting
`
`combination would not yield the invention recited in any of independent
`
`claims 1, 12, 23 or 30. For example, claims 1, 12, 23, and 30 each specify:
`
`writing a command in the update for the second computer
`to copy an old segment of the second computer's copy of
`the earlier version of the file into the second computer's
`copy of the current version of the file.
`
`A plain meaning reading of this requirement demands that a command to
`
`copy be written in the update that is used by the second computer to generate a
`
`copy of the current version of the file. Ex. 2009 at ¶ 19. The Balcha-Miller
`
`combination fails to teach or suggest same. Consequently, claims 1, 5, 9, 10,
`
`12, 16, 20, 21, 23, 24, 30, and 31 are patentable over the combination of
`
`Balcha and Miller.
`
`
`
`As illustrated in Figure
`
`3, reproduced here, Balcha,
`
`describes a scheme for
`
`reflecting the differences
`
`between two files (a base file
`
`and a revised file), within a
`
`  
`
`10  
`
`

`

`so-called “delta file.” In particular, 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. Ex.
`
`1003 at col. 7, l. 46 – col. 8, l. 6. Conveniently, 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.3
`
`
`As shown, the delta file includes certain “primitives,” which can be used to
`
`generate a copy of the revised file from the delta file. Specifically, Balcha uses
`
`primitives for “insert,” “modify,” and “delete.” Id. at col. 3, ll. 55-56. The
`
`                                                                                                                
`
`3 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 col. 13, ll. 40-42.
`
`
`
`  
`
`11  
`
`

`

`operation of these primitives is explained, with reference to the above example,
`
`at col. 14, ll. 5-19:4
`
`
`As shown in this example, 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. Id. at 14:5-19. Thereafter, and beginning at a location 5
`
`characters from the then-current pointer position, a 6-character string,
`
`“PAABST” is inserted. Id. Finally, the pointer position is advanced 5 characters
`
`and a 5-charater string is deleted. Id. 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”
`
`                                                                                                                
`4 In this exposition, the “⌃” character indicates the position of a pointer in the
`
`base file at which the corresponding primitive is applied. Id. at col. 13, l. 65 –
`
`col. 14, l. 1.
`
`  
`
`12  
`
`

`

`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.
`
`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. Ex. 2009 at ¶21. Consequently, Balcha has no 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.
`
`Id. Predictably then, Balcha neither teaches nor suggests writing such a
`
`command or other instruction for duplication into the delta file. Id.
`
`Dr. Hutchinson 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.” Ex. 1007 at ¶ 34. This
`
`conclusion is based on Balcha’s purported teaching of creation of a new file.
`
`However, Dr. Hutchinson later admitted in his deposition, “whether the base
`
`file is preserved and a new revised file is created or whether the base file is
`
`changed into the revised file is not immediately clear from this description.
`
`Both implementations might be possible.” Ex. 2011 at 14:17-21. Dr.
`
`  
`
`13  
`
`

`

`Hutchinson goes on to state his belief that Balcha is not “sufficiently precise to
`
`make a determination as to whether it [Balcha] is creating a new file or revising
`
`the original file.” Id. at 15:12-15. As such, Balcha cannot be relied upon to
`
`teach the creation of a new revised file. Thus, the logical underpinning of Dr.
`
`Hutchinson’s conclusion that Balcha calls for “commands embedded in the
`
`delta file [to] cause the unchanged bits to be effectively copied into the revised
`
`file” (Ex. 1007 at ¶ 34) is fundamentally flawed.
`
`Furthermore, and contrary to Dr. Hutchinson’s original conclusion,
`
`Balcha does not “effectively copy” over any bits from an old version of a file to a
`
`revised version of the file. Ex. 2009 at ¶ 22. Instead, the old file is converted to
`
`the revised file directly through execution of the insert and delete instructions
`
`included in the delta file. Id. 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 delta
`
`file and anything not deleted from, or modified within, the old version of the
`
`file remains in the revised version of the file. Id. citing Ex. 1003 at 13:64 – 65.
`
`To the extent Petitioners may argue that “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 Balcha, such “copies” do
`
`  
`
`14  
`
`

`

`not meet the requirements of Claims 1, 12, 23, and 30. These claims 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 written into the update.
`
`The creation of any “transitory copies” of files or portions thereof (e.g., copies
`
`of files that may be temporarily resident in volatile memory), on a computer are
`
`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.
`
`Thus, 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. Id. at ¶ 21. Considering these teachings in
`
`combination with those of Miller does not alter this situation.
`
`
`
` 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 computer file. Ex.
`
`  
`
`15  
`
`

`

`1004 at col. 1, ll. 10-15. An overview of that
`
`process is illustrated in Miller’s Figure 1,
`
`shown here.
`
`Miller’s DIFF file includes primitives
`
`for “copy,” “insert,” and “insert/copy”
`
`operations, which impart directives for
`
`handling stings that appear in new and old
`
`copies of the subject file. See, e.g., Ex. 1004
`
`at Fig. 5A. Importantly, from Miller’s
`
`perspective, the DIFF file must indicate changes between the old file and the
`
`new file in a minimum number of bytes so that the DIFF file is the smallest
`
`such file possible. Id. at col. 2, ll. 21-24, 31-33. Failing to use a file that was as
`
`small as possible would defeat Miller’s very objective. Ex. 2009 at ¶ 24.
`
`
`
`The Petitioners 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 method for updating data files.” See, e.g.,
`
`Unified Patents’ Petition at p. 17. Dr. Hutchinson’s declaration, Ex. 1007, is
`
`cited in support of this proposition, but neither the declaration nor either
`
`  
`
`16  
`
`

`

`Petition provides any analysis concerning the resulting outcome of the
`
`proposed combination of teachings.
`
`Obviousness requires more than a mere showing that the prior art
`
`includes separate references covering each separate limitation in a claim under
`
`examination. KSR Int’l, supra, at 418. Indeed, obviousness requires the
`
`additional showing that a person of ordinary skill at the time of the invention
`
`would have selected and combined those prior art elements in the normal
`
`course of research and development to yield the claimed invention. Id. at 421;
`
`see also Bayer Schering Pharm. AG v. Barr Labs., Inc., 575 F.3d 1341, 1350
`
`(Fed. Cir. 2009) (Newman, J., dissenting) ("The statutory criterion is whether
`
`the invention would have been obvious to persons of ordinary skill at the time
`
`of the invention, not whether it is sufficiently simple to appear obvious to
`
`judges after the discovery is finally made . . . ."). The present Petitions lack any
`
`such showing.
`
`
`
`This failure is not an oversight by Petitioners; for if one considers the
`
`true result of the combination of the Balcha-Miller teachings, it is readily
`
`apparent that this result is something other than the invention recited in
`
`independent claims 1, 12, 23, and 30 of the ‘799 Patent. Stated differently,
`
`Petitioners have carefully avoided providing a description of the result of the
`
`  
`
`17  
`
`

`

`proposed combination of Balcha and Miller, for once such an analysis is
`
`undertaken one can only conclude that claims 1, 12, 23, and 30, and their
`
`respective dependent claims, remain patentable over these references.
`
`
`
`Notice first that Petitioners do not contend that Balcha teaches, “writing
`
`[in the difference file] a command . . . to copy an old segment . . . of the earlier
`
`version of the file into . . . the current version of the file,” as recited in claims 1,
`
`12, 23, and 30. Indeed, it is apparent from the example reproduced above that
`
`Balcha never uses a command to copy in the delta file.
`
`Dr. Hutchinson attempts to finesse this point by stating,
`
`I also note that in the example shown at column 14 of
`Balcha the offsets on the delete and insert commands cause
`the skipped data bits to be carried over, or copied into the
`revised updated file. In other words, the commands
`embedded in the delta file cause the unchanged bits to be
`effectively copied into the revised file. 5
`
`This is factually incorrect. Ex. 2009 at ¶ 22. Balcha does not “effectively copy”
`
`over any bits from an old version of a file to a revised version of a file. Id.
`
`Instead, as shown quite clearly in the very example cited by Dr. Hutchinson,
`
`the old file is converted to the revised file directly through execution of the insert
`
`                                                                                                                
`  
`
`5 Ex. 1007 at ¶ 34.
`
`
`18  
`
`

`

`and delete instructions included in the delta file. No copying (or effective
`
`copying) is performed or required because the revised file is itself directly
`
`produced from the old file and the delta file. Id., and see Ex. 1003 at col. 13, ll.
`
`64 – 65 (“The following shows the application of the primitives in the delta file
`
`to a base file to generate a revised file.”) (emphasis added).
`
`Miller does teach the inclusion of a copy command in a DIFF file, Ex.
`
`1004 at col. 8, ll. 27-29, but Miller also stresses the importance of using the
`
`smallest DIFF file possible to reflect the changes between the old and new
`
`versions of the subject file. Id. at col. 2, ll. 31-33. When seeking to combine the
`
`teachings of references under Section 103, it is the entirety of the teachings that
`
`must be considered. W.L. Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d
`
`1540 (Fed. Cir. 1983), cert. denied, 469 U.S. 851 (1984). Hence, Petitioners
`
`cannot simply ignore or overlook the fact that Miller’s goal is to produce a
`
`smallest possible DIFF file, and indeed one of ordinary skill in the art would
`
`recognize that Balcha has proposed a difference file exactly in line with that
`
`goal.6 By avoiding the use of a copy command, Balcha necessarily reduces the
`
`number of bytes needed to convey information in the difference file. Ex. 2009
`
`                                                                                                                
`
`6 “The present invention reduces the amount of data necessary to reflect
`
`differences between two files . . . .” Ex. 1003 at col. 4, ll. 1-2.
`
`  
`
`19  
`
`

`

`at ¶ 21. Hence, when combining the teachings of Balcha and Miller, as
`
`proposed by Petitioners, it would be natural for a person of ordinary skill in the
`
`art to adopt the Balcha approach, and eliminate the need for a copy command.
`
`Id. at ¶ 24. Doing so would be in line with the stated goals of both cited
`
`references and indeed one would imagine the goal of the hypothetical person of
`
`ordinary skill inasmuch as reducing the number of bytes required in the
`
`difference file would save on transmission costs. Id., cf. Ex. 1004 at col. 1, ll.
`
`65-67 (noting that even compression schemes which reduce file sizes of up to
`
`40% may still leave resulting files that represent substantial transmission costs
`
`for distributers of those files).
`
`Additionally, according to Dr. Mohapatra, 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 unnecessarily and
`
`illogically added to the updated version of the file. Ex. 2009, at ¶ 24.
`
`Additionally, such 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. Id.
`
`  
`
`20  
`
`

`

`“To reach a proper determination under 35 U.S.C. § 103, [a fact finder]
`
`must step backward in time and into the shoes worn by the hypothetical
`
`‘person of ordinary skill in the art’ when the invention was unknown and just

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket