Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 1 of 33 PageID #: 1664
`
`IN THE UNITED STATES DISTRICT COURT
`FOR THE EASTERN DISTRICT OF TEXAS
`TYLER DIVISION
`
` §
`§
`§
`§
`§
`§
`§
`§
`
` §
`§
`§
`§
`§
`§
`§
`§
`
` §
`§
`§
`§
`§
`§
`§
`§
`
` §
`§
`§
`§
`§
`§
`§
`§
`
`
`
`
`
`
`
`
`
`
`
`
`
`UNILOC USA, INC., ET AL.
`Plaintiffs,
`
`
`vs.
`
`SONY CORPORATION OF AMERICA,
`ET AL.
`Defendants.
`
`
`UNILOC USA, INC., ET AL.
`Plaintiffs,
`
`
`vs.
`
`DISK DOCTORS LABS, INC., ET AL.
`Defendants.
`
`UNILOC USA, INC., ET AL.
`Plaintiffs,
`
`
`vs.
`
`NATIONAL INSTRUMENTS CORP., ET
`AL.
`
`Defendants.
`
`
`UNILOC USA, INC., ET AL.
`Plaintiffs,
`
`
`vs.
`
`ENGRASP, INC., ET AL.
`Defendants.
`
`CASE NO. 6:10-CV-373
`PATENT CASE
`
`CASE NO. 6:10-CV-471
`PATENT CASE
`
`CASE NO. 6:10-CV-472
`PATENT CASE
`
`CASE NO. 6:10-CV-591
`PATENT CASE
`
`Petitioner Ex. 1043 Page 1
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 2 of 33 PageID #: 1665
`
`CASE NO. 6:10-CV-636
`PATENT CASE
`
`CASE NO. 6:10-CV-691
`PATENT CASE
`
`CASE NO. 6:11-CV-33
`PATENT CASE
`
`
`
`
`
`
`
` §
`§
`§
`§
`§
`§
`§
`§
`
` §
`§
`§
`§
`§
`§
`§
`§
`
` §
`§
`§
`§
`§
`§
`§
` §
`
`
`
`
`
`UNILOC USA, INC., ET AL.
`Plaintiffs,
`
`
`vs.
`
`BMC SOFTWARE, INC., ET AL.
`Defendants.
`
`
`UNILOC USA, INC., ET AL.
`Plaintiffs,
`
`
`vs.
`
`FOXIT CORPORATION, ET AL.
`Defendants.
`
`
`SYMANTEC CORPORATION, ET AL.
`Plaintiffs,
`
`
`vs.
`
`UNILOC USA, INC., ET AL.
`Defendants.
`
`PLAINTIFF’S OPENING BRIEF ON CLAIM CONSTRUCTION
`
`
`
`
`
`ii
`
`
`
`Petitioner Ex. 1043 Page 2
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 3 of 33 PageID #: 1666
`
`
`
`TABLE OF CONTENTS
`
`I.
`
`INTRODUCTION ............................................................................................................... 1
`
`II. BACKGROUND ................................................................................................................. 1
`
`A. Overview of the Claimed Invention ............................................................................... 1
`
`B. Prior Litigation .............................................................................................................. 2
`
`C. Ex Parte Reexamination ................................................................................................ 3
`
` 1. Overview of Hellman ................................................................................................ 4
`
`
`
` 2. Overview of Grundy .................................................................................................. 6
`
`
`III. APPLICABLE LAW ......................................................................................................... 10
`
`A. Claim Construction ...................................................................................................... 10
`
`B. Doctrine of Prosecution History Disclaimer ............................................................... 12
`
`IV. THE PROPER CONSTRUCTION OF “PERMITS USE OF SAID DIGITAL
`DATA…ONLY IF…HAS MATCHED…” ...................................................................... 13
`
`V. UNILOC‟S EXPLANATION OF THE PRIOR ART DURING THE
`REEXAMINATION DOES NOT GIVE RISE TO ANY DISCLAIMER ....................... 14
`
`
`
`A. A Review of the Reexamination History Reveals That There is No Support for an
`Exclusion Related to Data Integrity Testing ............................................................... 15
`
`
`
` 1. The statements in response to the first office action do not constitute a
`disclaimer ................................................................................................................ 16
`
` 2. Statements in response to the second office action also fall short of a
` disclaimer ................................................................................................................ 20
`
`
`
`
`
` 3. Grundy dealt with a checksum, not a licensee unique ID ....................................... 21
`
` 4. Defendants‟ alleged disclaimer conflicts with the disclosed invention and creates
`a subjective test ....................................................................................................... 22
`
`
` B. Group B Defendants‟ Attempt to Limit the Types of Information Used to Generate
`a “Licensee Unique ID” Should be Rejected .............................................................. 23
`
`
`VI. CONCLUSION ................................................................................................................. 26
`
`
`
`
`
`
`iii
`
`Petitioner Ex. 1043 Page 3
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 4 of 33 PageID #: 1667
`
`TABLE OF AUTHORITIES
`
`
`
`
`
`CASES
`
` ACCO Brands, Inc. v. Micro Sec. Devices, Inc.
`346 F.3d 1075 (Fed. Cir. 2003) ......................................................................................... 24
`
`Alloc, Inc. v. Int’l Trade Comm’n,
`342 F.3d 1361 (Fed. Cir. 2003) ......................................................................................... 11
`
`Bayer AG v. Elan Pharm. Research Corp.
`212 F.3d 1241 (Fed. Cir. 2000) ......................................................................................... 12
`
`Bell Atl. Network Servs., Inc. v. Covad Commc’ns Group, Inc.
`262 F.3d 1258 (Fed. Cir. 2001) ......................................................................................... 11
`
`C.R. Bard, Inc. v. U.S. Surgical Corp.
`388 F.3d 858 (Fed. Cir. 2004) ...................................................................................... 10-11
`
`Comark Communs. v. Harris Corp.
`156 F.3d 1182 (Fed. Cir. 1998) ......................................................................................... 12
`
`Computer Docking Station Corp. v. Dell, Inc.
`519 F.3d 1366 (Fed. Cir. 2008) ........................................................................ 12-13, 15, 26
`
`Constant v. Advanced Micro-Devices, Inc.
`848 F.2d 1560 (Fed. Cir. 1988) ......................................................................................... 12
`
`Cordis Corp. v. Boston Sci. Corp.
`561 F.3d 1319 (Fed. Cir. 2009) ......................................................................................... 12
`
`Ecolab, Inc. v. FMC Corp.
`569 F.3d 1335 (Fed. Cir. 2009) ......................................................................................... 12
`
`Home Diagnostics, Inc., v. Lifescan, Inc.
`381 F.3d 1352 (Fed. Cir. 2004) ......................................................................................... 12
`
`Honeywell Int’l, Inc. v. Universal Avionics Sys. Corp.
`493 F.3d 1358 (Fed. Cir. 2007) ......................................................................................... 20
`
`In re Yamamoto
`740 F.2d 1569, 222 USPQ 934 (Fed. Cir. 1984) ............................................................... 25
`
`Innova/Pure Water Inc. v. Safari Water Filtration Sys., Inc.
`381 F.3d 1111 (Fed. Cir. 2004) ......................................................................................... 10
`
`
`
`iv
`
`Petitioner Ex. 1043 Page 4
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 5 of 33 PageID #: 1668
`
`
`Inverness Medical Switzerland v. Princeton Biomeditech Corp.
`309 F.3d 1365 (Fed. Cir. 2002) ......................................................................................... 25
`
`Markman v. Westview Instruments, Inc.
`52 F.3d 967 (Fed. Cir. 1995) ............................................................................................. 11
`
`O2 Micro Int'l Ltd. v. Beyond Innovation Tech. Co.
`521 F.3d 1351 (Fed. Cir. 2008) ......................................................................................... 14
`
`Omega Eng’g, Inc. v. Raytek Corp.
`334 F.3d 1314 (Fed. Cir. 2003) ......................................................................................... 12
`
`Orion IP, LLC v. Staples, Inc.
`406 F. Supp. 2d 717 (E.D. Tex. 2005) .............................................................................. 13
`
`Phillips v. AWH Corp.
`415 F.3d 1303 (Fed. Cir. 2005) ................................................................................... 10-13
`
`Teleflex, Inc. v. Ficosa N. Am. Corp.
`299 F.3d 1313 (Fed. Cir. 2002) ......................................................................................... 11
`
`Uniloc USA, Inc. v. Microsoft Corp.
`290 Fed. App‟x 337 (Fed. Cir. 2008) .................................................................................. 2
`
`Uniloc USA, Inc. v. Microsoft Corp.
`447 F. Supp. 2d 177 (D.R.I. 2006) ...................................................................................... 2
`
`Uniloc USA, Inc. v. Microsoft Corp.
`632 F.3d 1292 (Fed. Cir. 2011) ........................................................................................... 3
`
`Uniloc USA, Inc. v. Microsoft Corp.
`640 F. Supp. 2d 150 (D.R.I. 2009) ................................................................................... 2-3
`
`Vitronics Corp. v. Conceptronic, Inc.
`90 F.3d 1576 (Fed. Cir. 1996) ........................................................................................... 11
`
`
`
`OTHER
`
`35 U.S.C. § 103(a) ............................................................................................................... 4, 16, 26
`
`
`v
`
`
`
`
`
`Petitioner Ex. 1043 Page 5
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 6 of 33 PageID #: 1669
`
`I.
`
`INTRODUCTION
`
`Pursuant to the Court‟s Scheduling Order and P.R. 4-5(a), Plaintiffs Uniloc USA, Inc. and
`
`Uniloc Singapore Limited (“Uniloc”) hereby submit their opening brief on claim construction for
`
`the disputed terms and phrases in United States Patent No. 5,490,216 (the “„216 Patent”).
`
`As a preliminary matter, the Court should be aware that since the filing of the P.R. 4-3 Joint
`
`Claim Construction and Prehearing Statement, all 41 parties have agreed to the constructions of (1)
`
`“„Local‟ (in the phrase „local licensee unique ID generating means‟)” as “on the computer on which
`
`the digital data is executing or is to be executed”1 and (2) “comprises part of said digital data when
`
`executed on said platform” as “contained in said digital data when executed on said platform.”2
`
`This leaves only one disputed phrase, “permits use of said digital data . . . only if . . . has matched . .
`
`. .,”3 and Defendants‟ alleged disclaimer arguments as the subject of this brief.4
`
`II.
`
`BACKGROUND
`
`A. Overview of the Claimed Invention
`
`The „216 Patent5 describes a system and method for software activation to help prevent
`
`piracy. It does so by generating a local licensee unique ID (“LUID”) on the local computer where
`
`the software is installed and a remote licensee unique ID (“RUID”) at a remote registration
`
`authority. The LUID is generated for an intended licensee by inputting certain pieces of
`
`information into a local licensee unique ID generating means, which is generally a summer or a
`
`summation algorithm. The summer or summation algorithm preferably combines information
`
`1 Exh. A (partial email string between Steven Hartsell and Patrick Lujin dated September 1, 2011). Unless otherwise
`noted, all exhibits are attached to the supporting declaration of Steven W. Hartsell (“Hartsell Decl.”).
`2 Exh. B (email string between Jamie Olin and Patrick Lujin dated September 7-8, 2011).
`3 Uniloc notes that while it was able to reach agreement with the 40 remaining defendants, a lone defendant, Pervasive
`Software, Inc. (“Pervasive”), continues to seek leave to re-construe an additional term, namely the previously construed
`term “licensee unique ID.” Pervasive filed its Motion for Leave to Construe Previously Construed Term on August 29,
`2011 (Dkt. No. 243 in Case No. 6:10-cv-00472). Uniloc has not addressed this term as the Court has not granted leave
`as of the filing of this opening brief.
`4 The defendants have broken into two groups, each seeking a different alleged disclaimer. The Group A defendants
`consist of all defendants except those found in Group B. The Group B defendants consist of Aspyr Media, Inc., Borland
`Software Corp., Digital River, Inc., GEAR Software, Inc. and GEAR Software Holdings, Inc.
`5 Exh. C (copy of the „216 Patent).
`
`Petitioner Ex. 1043 Page 6
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 7 of 33 PageID #: 1670
`
`entered by a prospective user that is associated with that user, along with information provided by
`
`the environment on which the protected software is to run. These pieces of information are
`
`processed through the summer or summation algorithm to produce the LUID, which is a unique
`
`identifier associated with the user.
`
`The algorithm that generates the LUID is duplicated at a remotely located registration
`
`authority, generally under the control of the licensor. The algorithm on the remotely located
`
`registration authority then uses the same pieces of information to generate a RUID. The LUID and
`
`RUID are compared and if they match, the system will allow full, unrestricted use of the software.
`
`B. Prior Litigation
`
`The „216 Patent has a long litigation history, including a jury trial and multiple trips to the
`
`Federal Circuit. In September 2003, Uniloc sued Microsoft Corporation for infringement in the
`
`District Court for the District of Rhode Island. See Uniloc USA, Inc. v. Microsoft Corp., 640 F.
`
`Supp. 2d 150, 159 (D.R.I. 2009). The District Court conducted a Markman hearing and issued an
`
`order in August 2006 construing twenty-three terms and phrases. Uniloc USA, Inc. v. Microsoft
`
`Corp., 447 F. Supp. 2d 177 (D.R.I. 2006).
`
`In October 2007, the District Court granted Microsoft‟s motion for summary judgment of
`
`non-infringement. Uniloc appealed, and the Federal Circuit reversed the summary judgment. In
`
`reversing, the Federal Circuit considered and rejected “several alternative grounds for affirming the
`
`summary judgment beyond those which were reached by the district court” and concluded that they
`
`were without merit. The Federal Circuit also affirmed the construction of the term “licensee unique
`
`ID,” and explained that vendor-supplied information, such as Microsoft‟s Product Key, could
`
`provide the basis for a “licensee unique ID.” Uniloc USA, Inc. v. Microsoft Corp., 290 Fed. App‟x
`
`337, 343-44 (Fed. Cir. 2008) (“Uniloc I”).
`
`After a ten-day trial in April 2009, the jury found the „216 Patent valid and infringed, and
`
`
`
`2
`
`Petitioner Ex. 1043 Page 7
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 8 of 33 PageID #: 1671
`
`awarded Uniloc $388 million. Uniloc, 640 F. Supp. 2d at 160. Notwithstanding the jury verdict,
`
`the District Court granted Microsoft‟s post-trial motions for judgment as a matter of law of non-
`
`infringement and for a new trial on damages. Id. at 165-76, 183-85. The District Court also
`
`determined that: (1) U.S. Patent No. 4,658,093 (“Hellman”) did not anticipate the „216 Patent; and
`
`(2) the „216 Patent is not obvious in light of Hellman combined with U.S. Patent No. 4,796,220
`
`(“Wolfe”). Id. at 180-183. Both Uniloc and Microsoft appealed to the Federal Circuit.
`
`On January 4, 2011, the Federal Circuit reversed the District Court a second time on the
`
`issue of infringement, reinstating the jury‟s finding, but upheld the District Court‟s grant of a new
`
`trial on damages. Uniloc USA, Inc. v. Microsoft Corp., 632 F.3d 1292, 1323 (Fed. Cir. 2011)
`
`(“Uniloc II”). Characterizing the District Court‟s opinion as “comprehensive and well-reasoned,”
`
`the Federal Circuit also explicitly rejected Microsoft‟s arguments that the „216 Patent was
`
`anticipated by Hellman, noting that in accordance with the Federal Circuit‟s prior construction,
`
`Hellman failed to teach a “licensee unique ID” as claimed in the „216 Patent. Id. at 1301.
`
`The mandate of the Federal Circuit issued on May 23, 2011. The final pretrial conference
`
`for the new trial on damages is set for December 2011, with the trial expected to occur in early
`
`January 2012.
`
`C. Ex Parte Reexamination
`
`On January 22, 2010, a reexamination of the „216 Patent was instigated by Microsoft based
`
`primarily on United States Patent Nos. 4,658,093 to Hellman (“Hellman”) and 5,291,598 to Grundy
`
`(“Grundy”).6 The Patent Office granted the reexamination request on April 9, 2010. 7 Ultimately,
`
`
`6 The Examiner also cited United States Patent No. 4,796,220 to Wolfe but did not issue any substantive rejections
`based on Wolfe. See UNI075102 at n. 1. All references to UNIXXXXXX are found in Hartsell Decl. at Exh. D.
`Additionally, Uniloc also notes that Grundy was considered in the original prosecution and is found on the face of the
`„216 Patent. See Exh. C. Hellman was considered and rejected by the District of Rhode Island in the Microsoft
`litigation, see Uniloc USA, Inc. v. Microsoft Corp., 640 F. Supp. 2d 150, 179-183 (D.R.I. 2009), and that decision was
`affirmed by the Federal Circuit, see Uniloc II, 632 F.3d 1292, 1321-1323 (Fed. Cir. 2011). The Patent Office has
`recently confirmed all of the claims of the „216 Patent over both Hellman and Grundy. See UNI0076148-57.
`7 UNI074468-69.
`
`
`
`3
`
`Petitioner Ex. 1043 Page 8
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 9 of 33 PageID #: 1672
`
`the Patent Office confirmed all claims of the ‟216 Patent and issued a Notice of Intent to Issue
`
`Reexamination Certificate (“NIIRC”) on August 5, 2011.8
`
`The primary focus of the Patent Office‟s reexamination was a 35 U.S.C. § 103(a)
`
`obviousness rejection based on Hellman in view of Grundy.9 Uniloc disagreed with the Examiner‟s
`
`technical interpretations of how the disclosed systems in Hellman and Grundy operated. Uniloc‟s
`
`responses in the reexamination focused on correcting the Examiner‟s technical misunderstanding of
`
`the prior art. Ultimately, Uniloc was successful in explaining the technology of Hellman and
`
`Grundy to the Examiner and why these references could not properly be combined under § 103.
`
`Prior to addressing Defendants‟ constructions/disclaimers, Uniloc presents a summary of the
`
`substance of Hellman and Grundy. Having a high-level technical understanding of these two
`
`references will allow the Court to appreciate logical deficiencies in the Defendants‟ positions.
`
`1. Overview of Hellman10
`
`Hellman discloses a system that prevents software misuse by limiting the number of times
`
`that a base unit, e.g., a personal computer, is authorized to use a software program.11 To that end,
`
`authorizations are made to be specific to individual base units “so that an authorization for one base
`
`unit cannot be transferred to another base unit.”12
`
`An authorization unit at the software manufacturer (e.g., a server) uses a cryptographic
`
`function generator 23 to generate an authorization A.13 An identical cryptographic function
`
`generator 38 at the personal computer‟s cryptographic check unit 34 is used to generate a check
`
`
`8 UNI076148-57.
`9 UNI075022-30.
`10 The explanation of Hellman is derived from paragraphs 13-24 of the March 17, 2011 declaration of Dr. Udo Pooch
`that was submitted in connection with the reexamination. See UNI075642-720. The Patent Office stated that Dr.
`Pooch‟s declaration was “sufficient to overcome the rejection of claims 1-20 based upon Dr. Pooch‟s argument that it
`would be improper to combine the references in the manner of the claimed invention.” UNI076156 (Notice of Intent to
`Issue Reexamination Certificate).
`11 Exh. E at Abstract (Hellman patent); see also UNI075644 at ¶ 14.
`12 Id.; see also UNI075644 at ¶ 14.
`13 Id. at Figs. 1 and 2; see also UNI075644 at ¶ 15.
`
`
`
`4
`
`Petitioner Ex. 1043 Page 9
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 10 of 33 PageID #: 1673
`
`value C that must match the authorization A at comparator 39.14 If the check value C does not
`
`match Authorization A, A is not considered to be a proper authorization.15
`
`The cryptographic function generators 23 or 38 are an essential and critical element of
`
`Hellman‟s system. Hellman‟s cryptographic function generators are designed to be highly secure
`
`and to prevent would-be copiers from generating their own authorizations.16 Hellman describes
`
`three possible types of cryptographic functions that can serve as function generator 23 or 38, and
`
`unequivocally states that one of these cryptographic functions is “required to carry out the present
`
`invention.”17
`
`The first cryptographic function, described in FIG. 4 of Hellman, uses a modified Data
`
`Encryption Standard (“DES”).18 According to Hellman, “[t]he DES would have to be modified…to
`
`have its key length equal to the length of SK” so that it would work in the cryptographic function
`
`generator.19 Hellman teaches that this embodiment “would also inherently have the property t hat
`
`the new authorizations could not be predicted from old authorizations because, in a conventional
`
`cryptographic system, given past plaintext-ciphertext pairs, it must be difficult to determine the
`
`plaintext which goes with a new ciphertext.”20 The DES embodiment thus uses a robust and highly
`
`secure, cryptographic algorithm to generate an authorization code sufficiently secure to meet the
`
`rigorous needs of Hellman‟s system. At the time of Hellman, DES was considered a “military-
`
`grade” encryption technique.
`
`The second cryptographic function is shown in FIG. 9 and described as follows: “[s]ignals
`
`representing H, R and N are presented as a message to be signed by a public key cryptosystem 43
`
`
`14 Id. at Figs. 6 and 7; see also UNI075644 at ¶ 15.
`15 Id at Col. 10:24-26; see also UNI075644 at ¶ 15.
`16 Id. at Col. 7:4-16; UNI075644-45 at ¶ 16.
`17 Id. at Col. 2:61-65 (emphasis added); UNI075644-45 at ¶ 16.
`18 Id. at Col. 8:23-26; UNI075645 at ¶ 17.
`19 Id. at Col. 8:23-26; UNI075645 at ¶ 17.
`20 Id. at Col. 8:46-51; UNI075645 at ¶ 17.
`
`
`
`5
`
`Petitioner Ex. 1043 Page 10
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 11 of 33 PageID #: 1674
`
`using secret key SK to produce the digital signature,” which becomes authorization A.21 Like the
`
`DES embodiment, a public key cryptosystem is a highly secure, robust, cryptographic algorithm
`
`that meets the rigorous needs of Hellman‟s system. It is still in wide use today.
`
`The third cryptographic function is a one-way hash function. Hellman discloses that “[o]ne
`
`implementation of the cryptographic function generator 23 of FIG. 2 would also involve a one-way
`
`hash function . . . .”22 Again, a cryptographic one-way hash function is a robust, highly secure,
`
`cryptographic algorithm that meets the rigorous needs of Hellman‟s system. “One-Way” means
`
`that it is impossible to recreate the input of the hash function using the output of the function.
`
`Each of the alternative embodiments that Hellman describes to implement its cryptographic
`
`function generators 38 (i.e., DES, public/private key encryption, or cryptographic one-way hash
`
`algorithms) are sophisticated cryptographic algorithms. As noted earlier, Hellman unambiguously
`
`states that such cryptographic functions are “required to carry out the present invention.”23
`
`2. Overview of Grundy24
`
`Grundy is directed to a method and system for decentralized manufacture of copy-controlled
`
`software. As part of Grundy‟s system, Grundy describes the generation of a “registration code” that
`
`is used for communication between a new software user and what Grundy describes as a
`
`Manufacturing Control Agency.25
`
`As it relates to the „216 Patent reexamination, Grundy‟s use of “checksums” is of interest.
`
`A checksum is a value that (a) is computed by a function that is dependent on the contents of a data
`
`object and (b) is stored or transmitted together with the object, for detecting changes in data. A
`
`
`21 Id. at Col. 11:42-47; see also UNI075646 at ¶ 19.
`22 Id. at Col. 8:13-15; see also UNI075646 at ¶ 22.
`23 Id. at Col. 2:61-65 (emphasis added); see also UNI075647 at ¶ 24.
`24 The explanation of Grundy is derived from paragraphs 25-39 of the March 17, 2011 declaration of Dr. Udo Pooch
`that was submitted in connection with the reexamination. See UNI075642-720. The Patent Office stated that Dr.
`Pooch‟s declaration was “sufficient to overcome the rejection of claims 1-20 based upon Dr. Pooch‟s argument that it
`would be improper to combine the references in the manner of the claimed invention.” UNI076156 (Notice of Intent to
`Issue Reexamination Certificate).
`25 Exh. F at Col. 14:31-60 (Grundy patent); see also UNI075647 at ¶ 25.
`
`
`
`6
`
`Petitioner Ex. 1043 Page 11
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 12 of 33 PageID #: 1675
`
`checksum algorithm is a signature algorithm that does not attempt to provide cryptographic
`
`protection against inversion. The term “checksum” originally referred to checking algorithms that
`
`summed the bytes, but is now generally used to refer to any non-cryptographic checking
`
`algorithm.26 This is consistent with a contemporaneous definition of “checksum” from the filing of
`
`the „216 Patent and Grundy, which defines a “checksum” as:
`
`[A] calculated value that is used to test data integrity. Errors can occur when data is
`transmitted or when it is written to disk. One means of detecting such errors is use
`of a checksum, a value calculated for a given chunk of data by sequentially
`combining all the bytes of data with a series of arithmetic or logical operations.
`After the data is transmitted or stored, a new checksum can be calculated (using the
`possibly faulty transmitted or stored data) and compared with the original one. If the
`checksums don‟t match, an error occurred, and the data should be transmitted or
`stored again; if they do match, the transmission or storage was probably error-free.
`Checksums are a simple validation mechanism, and they cannot be used to correct
`erroneous data.27
`
`For example, prior to transmitting a 1000 character set of data, the sending computer may
`
`add each character together to form a checksum. The checksum may be only four characters long
`
`(undoubtedly, the true sum of a 1000 character data set would result in a number greater than four
`
`characters, but checksums typically only make use of a few digits of the total sum). The sending
`
`computer would then send the 1000 character set along with the four-character checksum to a
`
`receiving computer. The receiving computer would then use the same checksum algorithm used by
`
`the sending computer to sum up the 1000 character set and recreate the four-character checksum. If
`
`the checksum computed by the receiving computer matched the checksum it received from the
`
`transmitting computer, the receiving computer would assume that there were no errors in the
`
`transmission. If, however, the two checksum did not match, the receiving computer would
`
`conclude that the 1000 character set of data had not been transmitted accurately and would typically
`
`
`26 UNI075650 at ¶ 36.
`27 UNI075650 at ¶ 37; UNI075720.
`
`
`
`7
`
`Petitioner Ex. 1043 Page 12
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 13 of 33 PageID #: 1676
`
`request the transmitting computer to resend the data. Almost all Internet communications involve
`
`the exchange of checksums to help ensure data accuracy.
`
`Of importance to the reexamination, Grundy describes the use of checksum algorithms in
`
`the generation of certain data fields that ultimately make up the “registration code.” Specifically,
`
`Grundy teaches that the registration code consists of a packed bit array “with each field of the
`
`record occupying no more bits than is necessary to encode the information content of the field.”28
`
`There are six fields concatenated to form the registration code bit array.
`
`The first four fields are (1) a user data checksum, (2) a hardware ID code, (3) an anti-virus
`
`checksum, and (4) a previous owner‟s ID number. After these four fields are packed into the bit
`
`array, the array is encrypted, then (5) a Product/Version ID code is added, then (6) a data entry
`
`checksum is generated for the entire array and added to the array. Finally, the packed bit array is
`
`converted to an alphanumeric form to produce the registration code.29 The block diagram in Figure
`
`1 below represents how Grundy generates its registration code, which is a packed bit array:
`
`
`Figure 1: Block diagram of Grundy's concatenated registration code30
`
`
`
`
`28 Id. at Col. 18:61-64; see also UNI075647-48 at ¶ 27.
`29 Id. at Col. 18:58-64, 19:13-18; see also UNI075648 at ¶ 29.
`30 UNI075648.
`
`
`
`8
`
`Petitioner Ex. 1043 Page 13
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 14 of 33 PageID #: 1677
`
`
`
`As illustrated in the block labeled “X” in the upper-left hand corner of the above Figure, the
`
`operation that comprises the checksum of the user data component fields is a preliminary step for
`
`generating only the data that will later occupy the USER DATA CHECKSUM field of the packed
`
`bit array.
`
`During the reexamination, the Examiner erroneously asserted that Grundy produces a
`
`registration code by “performing a checksum of the user data component fields.”31 However, the
`
`Examiner‟s technical understanding of Grundy was flawed because, as discussed below, the
`
`checksum function does not create the registration code. Rather, the checksum function is a
`
`preliminary step to the creation of Grundy‟s “registration code.” Further, the checksums described
`
`in Grundy are not cryptographic functions, but rather appear to be used to check for typographical
`
`data entry errors or transmission errors.
`
`
`
`While the typical checksums are useful in detecting accidental modification such as
`
`corruption of stored data or errors in a communication channel, they provide no security against a
`
`malicious agent because their simple mathematical structure makes them trivial to circumvent. To
`
`provide a reliable level of security, the use of a cryptographic hash function is necessary.
`
`In one example, Grundy states for one of the checksums that “[t]his checksum will be used
`
`by the Manufacture Control Agency to avoid operator data-entry errors 304.”32 For another
`
`checksum, Grundy states that “[i]f the user data validity check 502 passes, a checksum of the user
`
`data is created 505. This checksum will be used during the Authorization process as a cross-
`
`reference to validate the user data as communicated to the Manufacture Control Agency 310 FIG.
`
`3.”33
`
`
`31 UNI075172.
`32 Exh. F at Col. 19:6-8, 15:3-24; see also UNI075649 at ¶ 34.
`33 Id. at Col. 18:25-29; see also UNI075649 at ¶ 34.
`
`
`
`9
`
`Petitioner Ex. 1043 Page 14
`
`

`
`Case 6:10-cv-00373-LED Document 202 Filed 09/12/11 Page 15 of 33 PageID #: 1678
`
`Grundy‟s checksums are quite distinct from cryptographic functions, which are used for
`
`different applications. If Grundy‟s checksums were to be used for security applications (as the
`
`Examiner asserted during the reexamination) they would be vulnerable to attack. For example, a
`
`checksum‟s linearity may be exploited by a malicious adversary.
`
`One of the Examiner‟s primary misconceptions in the reexamination was the role of
`
`checksum functions in Grundy. The Examiner mistakenly believed that the checksum in Grundy
`
`was used to generate the Grundy “registration code.” Grundy however, uses a checksum function
`
`for data entry error checking as a preliminary step to creating Grundy‟s “registration code.”
`
`Importantly, the checksum function does not produce the Grundy “registration code.” Rather, the
`
`checksum produces a value that is ultimately combined along with several other data items,
`
`encrypted and packed into a bit array, which is Grundy‟s “registration code.”
`
`Operating under this misconception, the Examiner substituted the checksum algorithm
`
`disclosed in Grundy in place of the sophisticated encryption algorithms disclosed in Hellman to
`
`arrive at a combination that the Examiner initially believed rendered obvious the claims of the „216
`
`Patent. But, after Uniloc educated the Examiner