Uniloc USA, Inc. et al v. NATIONAL INSTRUMENTS CORP. et al

Filing 265

Responsive CLAIM CONSTRUCTION BRIEF filed by FileMaker, Inc., Pervasive Software, Inc., Symantec Corp.. (Attachments: # 1 Exhibit 1 - '216 patent, # 2 Exhibit 2 - PTO Amendment, # 3 Exhibit 3 - Reply to PTO, # 4 Exhibit 4 - Response to PTO, # 5 Exhibit 5 - PTO Notice of Reexam, # 6 Exhibit 6 - PTO Dec of Pooch, # 7 Exhibit 7 - PTO Interview Summary, # 8 Exhibit 8 - PTO Dec of Rosenblatt)(Jones, Michael)

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

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.

§
§
§
§
§
§
§
§

CASE NO. 6:10-CV-636
PATENT CASE

§
§
§
§
§
§
§
§

CASE NO. 6:10-CV-691
PATENT CASE

§
§
§
§
§
§
§
§

CASE NO. 6:11-CV-33
PATENT CASE

DEFENDANTS’ RESPONSIVE BRIEF ON CLAIM CONSTRUCTION

Table of Contents
I. 

INTRODUCTION ...............................................................................................................1 

II. 

BACKGROUND .................................................................................................................1 
A. 

The ’216 Patent ........................................................................................................1 

III. 

APPLICABLE LAW ...........................................................................................................2 

IV. 

ARGUMENT .......................................................................................................................4 
A. 

Construction of “permits use of said digital data … only if [the local licensee
unique ID] has matched [the remote licensee unique ID].” (Claims 1, 19, 20) ......4 
1. 
2. 

B. 

Defendants’ Proposed Construction Should Be Adopted. ...........................5 
Clarification is Necessary in Light of Uniloc’s Infringement
Contentions. .................................................................................................8 

Reexamination Disclaimer: The Licensee Unique ID/Security Key Cannot Be
Generated by a Checksum, Summation Algorithm, Summer, or Equivalents
Thereof, Used to Test Data Integrity (All Asserted Claims) ...................................9 
1. 
2. 

C. 

Uniloc Clearly Disavowed Checksums from the Scope of the ’216
Patent..........................................................................................................11 
Defendants’ Proposed Disclaimer Is Narrowly Tailored to the Subject
Matter Disavowed by Uniloc .....................................................................13 

Additional Reexamination Disclaimer: The licensee unique ID generated by the
means recited in each of the claims must be derived from at least one piece of
information that is specific to the user, such as name, billing information, or
product information unique to the installation entered by the user. The
information cannot be specific to the computer or independently generated by the
computer (All Asserted Claims).............................................................................16 
1. 

Uniloc’s Disclaimer was Clear and Unequivocal. .....................................16 

2. 

The Scope of Uniloc’s Disclaimer is an Issue for the Court to Decide as
a Matter of Claim Construction. ................................................................17 

3. 

An Input That is “Unique to a Licensee” is Required to Output a
Licensee Unique ID. ..................................................................................19 

4. 

The Inputs Disclosed by Hellman Cannot be Used to Output a Licensee
Unique ID...................................................................................................20 

i

5. 
V. 

The NIIRC Appropriately Articulates the Scope of Uniloc’s
Disclaimer. .................................................................................................25 

CONCLUSION ..................................................................................................................26 

ii

Table of Authorities
Cases 
ACCO Brands, Inc. v. Micro Sec. Devices, Inc.,
346 F.3d 1075 (Fed. Cir. 2003)................................................................................................ 26
Chimie v. PPG Indus., Inc.,
402 F.3d 1371 (Fed. Cir. 2005).................................................................................................. 4
Gussin v. Nintendo of Am., Inc.,
62 F.3d 1433 (Fed. Cir. Aug. 3, 1995) ..................................................................................... 27
Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc.,
381 F.3d 1111 (Fed. Cir. 2004).................................................................................................. 3
Inverness Medical Switzerland v. Princeton Biomeditech Corp.,
309 F.3d 1365 (Fed. Cir. 2002)................................................................................................ 27
Markman v. Westview Instruments, Inc.,
517 U.S. 370 (1996) ................................................................................................................... 3
O2 Micro Int’l v. Beyond Innovation Tech.Co.,
521 F.3d 1351 (Fed. Cir. 2008)............................................................................................ 5, 10
On Demand Mach. Corp. v. Ingram Indus.,
442 F.3d 1331 (Fed. Cir. 2006).................................................................................................. 3
Ormco Corp. v. Align Tech. Inc.,
498 F.3d 1307 (Fed. Cir. 2007).................................................................................................. 4
Parallel Networks, LLC v. Abercrombie & Fitch,
No. 6:10cv111, 2011 WL 3609292 (E.D. Tex. Aug. 12, 2011) .............................................. 19
Phillips v. AWH Corp.,
415 F.3d 1303 (Fed. Cir. 2005) (en banc).......................................................................... 3, 4, 5
Research Plastics, Inc. v. Fed. Packaging Corp.,
421 F.3d 1290 (Fed. Cir. 2005).............................................................................................. 2, 3
Schindler Elevator Corp. v. Otis Elevator Co.,
593 F.3d 1275 (Fed. Cir. 2010)................................................................................................ 18
Southwall Techs., Inc. v. Cardinal IG Co.,
54 F.3d 1570 (Fed. Cir. 1995).................................................................................................... 4
Uniloc USA, Inc. v. Microsoft Corp.,
290 Fed. Appx. 337 (Fed. Cir. 2008) ................................................................................. 20, 21
iii

Uniloc USA, Inc. v. Microsoft Corp.,
632 F.3d 1292 (Fed. Cir. 2011).......................................................................................... 16, 22

iv

Table of Abbreviations
Uniloc

Plaintiffs Uniloc USA, Inc., Uniloc Singapore Limited and Uniloc
Luxembourg S.A.

OB

Uniloc’s Opening Brief on Claim Construction, Dkt. No. 257.
Docket number references in this brief are made with respect to the
docket for the Uniloc USA, Inc. et al v. National Instruments Corp.
et al., case number 6:10-CV-472. Corresponding filings are found
in each of the Uniloc related cases.

PTO

United States Patent and Trademark Office

The ’216 patent

U.S. Patent No. 5,490,216 (attached at Exhibit 1)

LUID

Local licensee unique ID

RUID

Remote licensee unique ID

NIIRC

Notice of Intent to Issue Ex Parte Reexamination Certificate
(attached as Exhibit 5)

All emphasis in this brief is added unless otherwise indicated.

v

I.

INTRODUCTION
As is evident from Uniloc’s opening brief (Dkt. No. 257, hereinafter “OB”), the parties

have succeeded in greatly narrowing the claim construction issues to be determined by the Court.
Only two issues remain: (1) the proper construction of the “permits use . . . only if” limitation
and (2) the scope of the disclaimers resulting from Uniloc’s statements to the United States
Patent and Trademark Office (“PTO”) during the recently concluded reexamination of the
patent-in-suit. Those issues are fully addressed below.
At the outset, however, Defendants would like to clarify a potentially misleading
contention in Uniloc’s brief. Specifically, Uniloc has stated that different groups of Defendants
assert that different disclaimers of claim scope result from the statements that Uniloc made to the
PTO. In actuality, all Defendants join in the arguments made with respect to the first disclaimer
issue (i.e., that Uniloc clearly and repeatedly disclaimed checksums and equivalent algorithms
used to test data integrity). A subset of Defendants (the group identified by Uniloc as the “Group
B” defendants) further contends that Uniloc is subject to the additional disclaimer regarding the
derivation of the licensee unique ID. None of the Defendants joining this Responsive Brief on
Claim Construction opposes the additional disclaimer.
II.

BACKGROUND
A.

The ’216 Patent

The patent-in-suit is United States Patent No. 5,490,216 (“the ’216 patent”),1 entitled
“System for Software Registration,” issued on February 6, 1996. The ’216 patent is directed to a
registration system to deter copying of software. Specifically, the patent is directed to a software
registration system wherein a particular piece of software may run on a platform in a “use mode”

1

A copy of which is submitted herewith as Exhibit 1.

1

(i.e. without restrictions) if and only if the licensing procedure described in the patent has taken
place. See ’216 patent at Abstract. In a representative embodiment of the claimed invention, a
user attempting to license software enters certain user information when prompted, including, for
example, the user’s name, telephone number, and address. Id. at Fig. 2b. Other information,
such as a locally generated serial number, based for example on the computer’s system time, can
also be used by the activation process. A “local licensee unique ID generating means” adds the
information entered by the user and other information into “a registration number unique to an
intending licensee,” or a “licensee unique ID.” See id. at Abstract. All this information is then
sent to the vendor’s system, which performs the identical algorithm using the same information
through a “remote licensee unique ID generating means,” thereby creating a “remote licensee
unique ID” and providing it to the user. Id. at 3:3-9. When the software is subsequently
initiated, a “mode-switching means” compares the local and remote licensee unique IDs. Id. at
4:30-44. If the two match, the mode switching means permits the user to access the “use mode”
of the software. Id. However if the two codes do not match, the mode switching means confines
the user to a “demo mode” with limited functionality. Id.
III.

APPLICABLE LAW
Claim construction begins with the language of the claims. Research Plastics, Inc. v.

Fed. Packaging Corp., 421 F.3d 1290, 1295 (Fed. Cir. 2005). “The words of a claim are
generally to be accorded their ‘ordinary and customary meaning,’ which is ‘the meaning that the
term would have to a person of ordinary skill in the art in question at the time of the invention.’”
Id. (quoting Phillips v. AWH Corp., 415 F.3d 1303, 1313 (Fed. Cir. 2005) (en banc)). To
properly construe the claims, courts should look to sources that show what a person of skill in the
art would have understood the disputed claim language to mean, including “the words of the
2

claims themselves, the remainder of the specification, the prosecution history, and extrinsic
evidence concerning relevant scientific principles, the meaning of technical terms, and the state
of the art.” Phillips, 415 F.3d at 1314 (quoting Innova/Pure Water, Inc. v. Safari Water
Filtration Sys., Inc., 381 F.3d 1111, 1116 (Fed. Cir. 2004)).
The patent specification is always highly relevant to claim construction. Phillips, 415
F.3d at 1315-17. Every claim term, irrespective of how basic of a term it might be, must be read
in light of the specification. Id. at 1313. Indeed, claim terms can be defined only in ways that
comport with, and are consistent with, the specification as a whole. Id. at 1316 (citing Markman
v. Westview Instruments, Inc., 517 U.S. 370, 389 (1996)). It is axiomatic that “the claims cannot
be of broader scope than the invention that is set forth in the specification.” On Demand Mach.
Corp. v. Ingram Indus., 442 F.3d 1331, 1340 (Fed. Cir. 2006) (reversing district court’s
overbroad construction of “customer” where the specification “repeatedly reinforce[d] its usage
of the term ‘customer’ as the retail consumer”); see also Ormco Corp. v. Align Tech. Inc., 498
F.3d 1307, 1313-16 (Fed. Cir. 2007) (“[T]o attribute to the claims a meaning broader than any
indicated in the patents and their prosecution history would be to ignore the totality of the facts
of the case and exalt slogans over real meaning.”). “The construction that stays true to the claim
language and most naturally aligns with the patent’s description of the invention will be, in the
end, the correct construction.” Phillips, 415 F.3d at 1316.
Like the specification, the prosecution history “can often inform the meaning of the claim
language by demonstrating how the inventor understood the invention and whether the inventor
limited the invention in the course of prosecution, making the claim scope narrower than it
would otherwise be.” Id. at 1317; see also Chimie v. PPG Indus., Inc., 402 F.3d 1371, 1384
(Fed. Cir. 2005). Explicit statements made by a patent applicant during prosecution and

3

reexamination to distinguish a claimed invention over prior art serve to narrow the scope of a
claim. Southwall Techs., Inc. v. Cardinal IG Co., 54 F.3d 1570, 1576 (Fed. Cir. 1995).
While the “[w]ords of a claim are generally given their ordinary and customary
meaning,” a determination “that a claim term ‘needs no construction’ or has the ‘plain and
ordinary meaning’ may be inadequate when a term has more than one ‘ordinary’ meaning or
when reliance on a term’s ‘ordinary’ meaning does not resolve the parties’ dispute.” O2 Micro
Int’l v. Beyond Innovation Tech.Co., 521 F.3d 1351, 1360-61 (Fed. Cir. 2008). Thus, “[w]hen
the parties present a fundamental dispute regarding the scope of a claim term, it is the court’s
duty to resolve it.” Id. at 1362.
IV.

ARGUMENT
A.

Construction of “permits use of said digital data … only if [the local licensee
unique ID] has matched [the remote licensee unique ID].” (Claims 1, 19, 20)

This phrase means that “when [the local and remote licensee unique IDs] have matched
then the use of said digital data is permitted.” In other words, it is the matching of the two
licensee unique IDs that permits or causes the use of the digital data.
While Uniloc takes the position that this phrase should not be construed, its infringement
contentions suggest that Uniloc intends to argue that the matching of the two licensee unique IDs
need not be the condition that permits or causes the use of the digital data. Rather, Uniloc’s
apparent interpretation of this term would only require that such matching precede in time the
use of the digital data without requiring a causal relationship between the matching and
permitting of use. Accordingly, an actual dispute regarding the scope of this term exists and
should be resolved by the Court See O2 Micro Int’l, 521 F.3d at 1362-63.

4

1.

Defendants’ Proposed Construction Should Be Adopted.

Defendants’ proposed construction is consistent with the ordinary and customary
meaning of the claim language – which is “the meaning that the term would have to a person of
ordinary skill in the art in question at the time of the invention.” Phillips, 415 F.3d at 1314. This
ordinary meaning is informed by the context of the claims, the specification and the prosecution
history.
The ’216 patent specification describes a registration system that compares a locally
generated licensee unique ID with a remotely generated licensee unique ID. If the two IDs
match, the software is activated – i.e., the matching of the two IDs is the condition that causes
activation. For example, the specification states that “[i]n broad terms, the system according to
the invention is designed and adapted to allow digital data or software to run in a use mode on a
platform if and only if an appropriate licensing procedure has been followed.” ’216 patent at
col. 2:52-55. As the parties have agreed, the term “has matched” as used in claim 1 was
correctly construed in the prior litigation as “a comparison between the locally generated
licensee unique ID… and the remotely generated licensee unique ID… shows that the two are
the same.” Dkt. No. 247 (Jt. Claim Constr. Stmt. at 8).
The bulk of the description in the specification concerning this matching process appears
in connection with the “First Embodiment” and the “Seventh Embodiment.” The discussion
concerning other embodiments either does not address this matching in detail or states that this
operation takes place as described in the First Embodiment. See, e.g., ’216 patent at col. 10:4244 (“This registration procedure is as previously described with reference to the first
embodiment.”); see also id. at 11:44-46 (“operates in the manner generally described in respect
of previous embodiments”).

5

The First Embodiment describes the matching algorithm with reference to FIG. 2. This
description and FIG. 2 show that the matching of the licensee unique IDs is at the heart of the
registration process disclosed in the ’216 patent:
As a final stage in registration (refer to FIG. 2d [sic – 2c]), the registration
authority 16 provides the registration number generated by the registration
authority PC 15 to the user 11. The user 11 enters the registration number into the
user PC 12 where the registration routine checks to see whether the entered
registration number matches the calculated registration number. If the two
match, then a valid registration has taken place and access is provided by the
registration routine to a full operating version of the software protected by the
registration routine. If there is no match and a preference file (which stores the
user details) does not exist then a dialogue box D (FIG. 2c) appears on the display
13 of user PC 12 providing the prospective new user 11 with the opportunity to
check his/her details or switch to the demonstration version of the software
protected by the registration routine.
’216 patent at col. 7:36-50.
FIG. 2c graphically depicts this process, showing that when the IDs match, the full
version of the software is run. Conversely, if there is no match, the software is run on “Demo”
version:

6

Like Defendants’ construction, this description shows that there is a causal relationship between
the matching of local and remote licensee unique IDs and the valid registration of the software.
The Seventh Embodiment employs this same approach, but describes it in somewhat
different language: “When mode switcher 68 verifies the match, then the mode switcher 68
allows execution on platform 31 of the full user program 39.” ’216 patent at col. 11:63-65.
Defendants’ construction aligns precisely with the specification’s description of the claimed
invention.
Moreover, during the original prosecution of its application, Uniloc explicitly argued that
its invention was distinguishable over the prior art because the simple matching of the local
licensee unique ID (LUID) with the remote licensee unique ID (RUID) caused the activation. In
contrast, the prior art provided for matching, but also had to take into account additional
information added by the remote computer before use of the software was permitted:
Because additional information is added at the remote computer in Grundy, it
follows automatically that a simple comparison or match of the registration code
derived from the local computer and the authorization code derived from the
remote computer is not possible. … Accordingly, Claim 1 of the present
application which requires a match of the local license[e] unique ID with the
remote licensee unique ID is patentably distinguished over the fundamentally
more complex process outlined in Grundy.
’216 file history, Amendment in Response to June 24, 1994 Office Action (dated Dec. 21, 1994)2
at pp. 4-5 (UNI000129-130).
Uniloc itself recognizes that the ’216 patent “describes a system and method for software
activation” in which “[t]he LUID and RUID are compared and if they match, the system will
allow full, unrestricted use of the software.” OB at pp. 1-2. Accordingly, this term should be
construed so as to be consistent with the specification and the prosecution history to mean that

2

A copy of which is submitted herewith as Exhibit 2.

7

when the local and remote licensee unique IDs match, then the use of the digital data permitted.
2.

Clarification Is Necessary in Light of Uniloc’s Infringement Contentions.

Uniloc does not assert that Defendants’ construction is incorrect. Rather, it says that it is
“unnecessary.” OB at pp. 13-14. Yet Uniloc’s infringement contentions as to Defendant Intuit
demonstrate that there is a fundamental dispute between the parties regarding the scope of the
claim term. Uniloc’s contentions state that the “permits use … only if” limitation is satisfied in
circumstances where there is no causal relationship between the matching and the subsequent
permitted use. Instead, all that Uniloc’s infringement contentions state is that “[i]f the two
identifier [sic] (i.e., licensee unique IDs) match, this indicates that the unique licensee
information is legitimate.” See e.g., Exhibit A to Declaration of Hector J. Ribera in Support of
Defendants’ Responsive Brief on Claim Construction, (Uniloc Preliminary Infringement
Contentions, Ex. A: U.S. Patent No. 5,490,216 v. Intuit, at p. 11).
The claims of the ’216 patent at issue here, however, are not about matching to determine
if licensee unique IDs are “legitimate.” Rather, the patent teaches that when the licensee unique
IDs match, “then a valid registration has taken place and access is provided by the registration
routine to a full operating version of the software protected by the registration routine.” ’216
patent at col. 7:43-45. One of the benefits of such a system may be ensuring that the same
details entered by the user are those entered in the remote registration system (see, e.g., id. at col.
7:61-64), but that does not mean Uniloc can eliminate the causal relationship between matching
and providing access and thereby read out the “permits use … only if” limitation. There is
nothing in the ’216 patent that suggests determining “legitimacy” of a licensee unique ID
“permits use” of the software. Simply stated, the ’216 patent does not support the broader scope
of this term that Uniloc apparently intends to pursue for infringement purposes.

8

Uniloc’s refusal to agree to Defendants’ proposed construction provides a clear indication
that it intends to argue to the jury infringement based on a supposed “ordinary meaning” that is
inconsistent with the specification’s disclosure. If, as Uniloc alleges, Defendants’ proposed
construction is nothing more than a rearrangement of the same words (see OB at pp. 13-14), then
Uniloc should have no objection to the adoption of Defendants’ proposal. Yet it has opposed
Defendants’ proposed construction without providing an alternative. Thus, the parties have a
real dispute as to the scope of this claim limitation which should be resolved by the Court. See
O2 Micro Int’l, 521 F.3d at 1362-63 (holding that “[w]hen the parties present a fundamental
dispute regarding the scope of a claim term, it is the court’s duty to resolve it.”).
In the context of the ’216 patent specification, the “permits use … only if” limitation
means that when there is a match between the local and remote licensee unique IDs, then the use
of said digital data is permitted. Uniloc should not be allowed to make arguments to the jury
inconsistent with this construction. Moreover, having failed to even propose an alternative
construction for this term and simply requested that the Court not construe the term, Uniloc
should be precluded from advancing any new proposed construction at this late stage. Therefore,
Defendants request that the Court adopt their proposed construction.
B.

Reexamination Disclaimer: The Licensee Unique ID/Security Key Cannot
Be Generated by a Checksum, Summation Algorithm, Summer, or
Equivalents Thereof, Used to Test Data Integrity (All Asserted Claims)3

In its Opening Brief, Uniloc acknowledges that express disclaimers made to the PTO in
order to overcome prior art rejections are limiting. During the reexamination of the ’216 patent,
the PTO rejected all of the claims in light of the Hellman and Grundy prior art references. To
overcome these rejections, Uniloc made explicit and repeated statements to the PTO regarding

3

As noted above, and contrary to Uniloc’s assertions, all Defendants join in this position.

9

what its claims did and did not cover. While Uniloc now tries to avoid the impact of these
statements by calling them “explanations” rather than “disclaimers,” there is no such distinction
in the patent law. The reality is that Uniloc’s repeated assertions made to overcome the
rejections, whether or not they were “explanations” – and whether or not they were made as part
of a discussion of how two prior art references could work together – operate as disclaimers.
Uniloc’s disclaimers during the reexamination were clear and unmistakable. Uniloc
argued that Grundy does not disclose a feature required in all claims of the patent – i.e., “a
unique identifier associated with a licensee.” Uniloc repeatedly stated that a “checksum” cannot
be a unique identifier associated with a licensee because, inter alia, “a checksum cannot
preserve the uniqueness of the input data,” and thus, “is not a generator of unique identifiers.”
Uniloc’s responses to the PTO’s rejections, including supporting presentation material and two
expert declarations, are replete with similar statements (set forth below) that unequivocally
disclaim checksums.
Faced with these explicit and unconditional statements as to what the claims of the
’216 patent do not cover, Uniloc essentially concedes in its Opening Brief that it disclaimed
checksums. Uniloc argues, however, that any such disclaimer should be limited to “checksum
algorithms such as the one shown in Grundy.” OB at p. 21. Tellingly, Uniloc offers no proposed
language of its own as to the proper scope of the disclaimer. As shown below, Defendants’
proposed disclaimer – that “the licensee unique ID/security key cannot be generated by a
checksum, summation algorithm, summer, or equivalent thereof, used to test data integrity” –
is in fact narrowly tailored to the subject matter clearly and unequivocally disclaimed by Uniloc.

10

1.

Uniloc Clearly Disavowed Checksums From the Scope of the ’216 Patent

In its response to the first office action rejecting all claims of the ’216 patent in light of
Hellman and Grundy, Uniloc first emphasized that each claim of the patent requires “a unique
identifier associated with a licensee”:
The invention implements a unique identifier that is associated with a licensee
as a means for licensing execution (or controlling use) of software to (or by) an
intended licensee. This feature is present in each of the independent claims.
For example, in independent claims 1, 19 and 20, this feature is a “licensee unique
ID.” In claim 12 this feature is a “security key.” In claim 17 this feature is a
“registration key” and an “enabling key.”4
Reply to First Office Action, filed Nov. 29, 2010,5 p. 17 (UNI075102).
Next, Uniloc repeatedly told the PTO that a checksum did not provide this required
feature, as a checksum cannot be, or generate, a “unique identifier that is associated with a
licensee”:
[A] checksum is not unique and therefore cannot be a unique identifier
associated with a licensee.
Id., p. 33 (UNI075118).
Therefore, a checksum cannot preserve the uniqueness of the input data.
Grundy shows the input data to the checksum routine in Fig. 2, 212, “ENTER
NEW USER DETAILS.” This is “new user data, such as the user’s name,
address and telephone number” (Grundy at 12:37-38.) Such data might take up
roughly a hundred bytes of data. A checksum of this data would not preserve its
uniqueness; many different sets of user data could produce the same checksum.
Therefore the checksum is not a generator of unique identifiers.
Id., p. 27 (UNI075112).
[A] checksum cannot preserve the uniqueness of the input data and thus the
checksum is not a generator of unique identifiers.

4

In addition, Uniloc notified the examiner that the district court in Uniloc USA, Inc. et al. v. Microsoft Corp., Case
No. 03-440 (D.R.I.) also construed the terms “licensee unique ID,” “security key,” “registration key,” and “enabling
key” to mean “a unique identifier associated with a licensee,” and that this construction had been affirmed by the
Federal Circuit. Reply to Office Action, filed Nov. 29, 2010.
5

A copy of which is submitted herewith as Exhibit 3.

11

Id., p. 32 (UNI075117).
Uniloc continued making similar statements in its response to the second office action:
Uniloc also argued that Grundy’s checksum did not generate “a licensee unique
ID” because Grundy’s checksum algorithm, by its very nature, destroys any
uniqueness.
Reply to Second Office Action, filed Mar. 18, 2011,6 p. 16 (UNI075203).
However, if these references are combined as the Examiner suggests, with
Grundy’s error-checking checksum replacing Hellman’s cryptographic function
generator, the Examiner can no longer take credit for the ‘uniqueness’ feature
provided by Hellman because the source of that uniqueness, the one-way
compressive hash function having a 100:1 X/Y bit ratio, would also be replaced
by Grundy’s checksum.
Id., p. 34 (UNI075221).
The basis for this determination was that the Requester attempted to rely on
Grundy’s checksums; and, according to the Office, Grundy’s “[c]hecksums are
not unique fields, even if there [sic] are at least in part derived from unique
data.”
Id., p. 43 (UNI075230). These statements and numerous others that Uniloc made in order to
overcome prior art rejections and obtain its patent, compel a finding that the claims are limited
by Defendants’ proposed disclaimer. See generally Exhibits 3 and 4.
Uniloc now attempts to hide its explicit disclaimer behind the guise of “correcting the
Examiner’s technical misunderstanding of the prior art” and explaining why the algorithms
disclosed in one prior art reference could not be combined with another. Uniloc cherry-picks
quotes to make it appear that its efforts in reexamination were focused on picayune distinctions
having to do with the purpose for which checksums were used in particular prior art references.
But that is not all Uniloc was doing. Instead, as the excerpts quoted above reveal, in an effort to
save its patent, Uniloc represented that (1) the claims require something that checksum
algorithms, by virtue of being checksum algorithms, cannot create; and (2) checksum algorithms,
6

A copy of which is submitted herewith as Exhibit 4.

12

by virtue of being checksum algorithms used to test data integrity, cannot generate a unique
identifier associated with a licensee. The effect of this unequivocal disavowal was to limit the
claims to exclude checksums.
That this disavowal was clear and unmistakable is further confirmed by the Examiner.
He relied on Uniloc’s repeated and express disclaimers stating, inter alia:
The Patent Owner has persuasively argued that the summation disclosed in
Grundy is used in the context of merely verifying the correctness of information
related to the user and is not being used to generate an ID per se. Since the
information is not being used for the same purpose, one skilled in the art therefore
would not use the algorithm of Grundy as part of the generation of the claimed
licensee unique ID.
Notice of Intent to Issue Ex Parte Reexamination Certificate (“NIIRC”),7 at p. 6 (UNI076155).
2.

Defendants’ Proposed Disclaimer Is Narrowly Tailored to the Subject
Matter Disavowed by Uniloc

With little other choice, Uniloc essentially admits that it disclaimed checksums, but
focuses on the scope of the proposed disclaimer:
Assuming, arguendo, that the Defendants are correct that some of Uniloc’s
statements about Grundy amount to a disclaimer, at most such an alleged
“disclaimer” should only apply to checksum algorithms such as the one shown in
Grundy and not summation algorithms in general “used to test data integrity” as
urged by Defendants.”
OB at p. 21.
Uniloc attests that the proposed disclaimer is vague and goes too far, arguing that the
’216 patent teaches that the local unique ID (“LUID”) generating means and remote unique ID
(“RUID”) generating means “act as a test of data integrity because if the inputs are not identical
the outputs would not match.” Id. at pp. 22-23.

7

A copy of which is submitted herewith as Exhibit 5.

13

Uniloc’s argument is a red-herring. “Data integrity” is a well-understood term to those of
skill in the art. Indeed, Uniloc’s definition of “checksum” in its Opening Brief conveys the
meaning of “data integrity.” According to Uniloc itself, a checksum is:
[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.
Id. at p. 7; Declaration of Dr. Udo W. Pooch Under 37 C.F.R. § 1.132,8 ¶ 37 (UNI075650).
In contrast, the summation algorithm described in the ’216 patent is not being used to
check for data integrity (e.g., to check data after a transmission or storage operation). The ’216
patent teaches that a user who chooses to register software is prompted to enter unique, personal
information of the user – such as name, address, and a credit card number. This information is
passed to a registration number algorithm (i.e., a summation algorithm) which generates the
LUID. The user conveys the same information to a remote registration center which generates
an RUID using the same registration number algorithm. If the LUID and RUID match, the
software becomes registered. In other words, the ’216 patent algorithm is concerned with
creation of an identifier (the LUID) that will become a unique and permanent value for
continuously securing access to the software. This is not the same as merely checking accuracy
of data after transmission or storage. Uniloc’s statement that it did not “disclaim the use of
checksums or algorithms used to test data integrity to generate licensee unique IDs” is thus

8

A copy of which is submitted herewith as Exhibit 6.

14

inaccurate– “testing data integrity” and “generating licensee unique IDs” are different and
largely unrelated functions.
In short, as Uniloc repeatedly argued in attempting to overcome Grundy, and as the PTO
recognized, a checksum (or summation) algorithm used for “merely verifying the correctness of
information” (i.e., to ensure data integrity) does not and cannot generate a licensee unique ID.
See supra at section IV.B.1.
Defendants’ proposed disclaimer adopts the very definition of “checksum” that Uniloc
itself expressly propounded – both during the reexamination in order to overcome the prior art
and in its Opening Brief: “A calculated value used to test data integrity.” If anything,
Defendants’ proposed disclaimer is more limited than Uniloc’s actual disclaimer because it
specifies “checksum, summation algorithm, summer, or equivalent thereof, used to test data
integrity” as opposed to any algorithm used to calculate a value.
Despite the clarity, extent and unambiguous nature of its disclaimer, Uniloc also seeks to
change its scope by arguing that the phrase “used to test data integrity” creates a subjective test.
OB at p. 23. This argument lacks merit. As reflected above, determining whether a checksum,
summation algorithm, summer, or equivalent is used to test data integrity is an objective inquiry
that asks what the algorithm does, and has nothing to do with the state of mind of the
programmer.
Lastly, Uniloc argues that Defendants’ proposed disclaimer would alter the Federal
Circuit’s findings “to conclude that MD5 hash values may infringe under some circumstances
but not others.” OB at p. 23. Uniloc’s argument incorrectly assumes that the Federal Circuit
found that an MD5 hash value must be an LUID in all instances, regardless of its inputs or what
it is used to do. That is demonstrably wrong. In Microsoft, the MD5 hash value calculated on

15

the client was compared to the MD5 hash value calculated on the server, and “if they match, the
software product is activated.” Uniloc USA, Inc. v. Microsoft Corp., 632 F.3d 1292, 1299 (Fed.
Cir. 2011) (“Uniloc II”). Thus, the MD5 algorithm in that case was used to determine whether to
activate the software, not to test data integrity. There is nothing in that finding that says that all
uses of an MD5 hash must infringe. Moreover, now that Uniloc has disclaimed checksums, an
MD5 hash used as a checksum to test data integrity cannot possibly constitute infringement.
Given the clear, repeated, and unmistakable statements by Uniloc that “a checksum is not unique
and therefore cannot be a unique identifier associated with a licensee,” the proposed disclaimer
does not contradict any findings made by the Federal Circuit.
C.

Additional Reexamination Disclaimer: The licensee unique ID generated by
the means recited in each of the claims must be derived from at least one
piece of information that is specific to the user, such as name, billing
information, or product information unique to the installation entered by the
user. The information cannot be specific to the computer or independently
generated by the computer (All Asserted Claims)9

During the reexamination, Uniloc repeatedly distinguished its invention from that
disclosed in the Hellman reference by stating that (1) the licensee unique IDs in the ’216 patent
had to be derived from at least one piece of information that is specific to the user, and (2) none
of the inputs to the hash algorithm disclosed in Hellman satisfies that requirement. The
Examiner expressly relied upon these statements in confirming the patentability of the claims of
the ’216 patent.
1.

Uniloc’s Disclaimer Was Clear and Unequivocal.

Uniloc’s disclaimer of claim scope over the Hellman reference was clear and
unequivocal. Uniloc argued that Hellman does not disclose a feature required in all claims of the
9

Defendants Aspyr Media, Inc., Borland Software Corp., Digital River, Inc., GEAR Software, Inc. and GEAR
Software Holdings, Inc. (the “Group B” defendants) join in this position. They seek this disclaimer in addition to
the disclaimer discussed in the prior section. The disclaimers are directed to different aspects of the claims, and this
Court should adopt both. No Defendants joining this brief oppose this position.

16

patent – i.e., “a unique identifier associated with a licensee.” Uniloc argued that the registration
code generated by the hash algorithm of Hellman cannot be a unique identifier associated with a
licensee because, inter alia, “none of the input signals to Hellman’s cryptographic function
generator 38 (or 23)—namely, K (or SK), N, R, and H—are unique to a licensee and therefore
cannot disclose the ‘local licensee unique ID’ of claim 1.” See, e.g., Exhibit 3 (Reply to First
Office Action, filed Nov. 29, 2010), at p. 21 (UNI07106).
Uniloc repeated this argument throughout its responses to the PTO and throughout the
expert declarations submitted on its behalf. These statements conclusively establish two points.
First, an input that is “unique to a licensee” is required to output a licensee unique ID. Second,
the inputs of Hellman cannot be used to output a licensee unique ID. Uniloc has therefore
disclaimed the inputs disclosed in Hellman as unique to a licensee. The examiner explicitly
relied on Uniloc’s disclaimer of Hellman’s inputs in the Notice of Intent to Issue Ex Parte
Reexamination Certificate (“NIIRC”). The Court should adopt the Examiner’s articulation of
Uniloc’s disclaimer as set forth in the NIIRC:
The licensee unique ID generated by the means recited in each of the claims must
be derived from at least [one] piece of information that is specific to the user, such
as name, billing information, or product information unique to the instantiation
entered by the user. The information cannot be specific to the computer or
independently generated by the computer.
Exhibit 5 (NIIRC) at p. 5 (UNI076154).
2.

The Scope of Uniloc’s Disclaimer Is an Issue for the Court to Decide as a
Matter of Claim Construction.

Claim construction is, of course, an issue for the Court, and the extent of Uniloc’s
disclaimer is one of claim scope. Schindler Elevator Corp. v. Otis Elevator Co., 593 F.3d 1275,
1285 (Fed. Cir. 2010) (stating that disclaimer is disavowal of “any claim interpretation that
would effectively eliminate the limitation or that would otherwise recapture the claim’s original

17

scope”); Parallel Networks, LLC v. Abercrombie & Fitch, No. 6:10cv111, 2011 WL 3609292, at
*5 (E.D. Tex. Aug. 12, 2011) (Davis, J.) (Markman Order) (concluding that patentee disavowed
claim scope when distinguishing prior art to the examiner). Because Uniloc disclaimed certain
inputs to a generating means as not being associated with a user, the parties should not have to
argue to the jury whether these disclaimed inputs are associated with a user.
The construction of “licensee unique ID” from the Microsoft case is not sufficient to
apprise the jury of the proper scope of the asserted claims of the ’216 patent. That
construction—“a unique identifier associated with a licensee”—does not by itself indicate what
types of inputs are required in order for the identifier to be associated with a licensee. Since
originally articulated in the Microsoft case, this construction has been narrowed by the Federal
Circuit and by Uniloc. The jury in this case should be instructed in accordance with this
narrowing.
Moreover, Uniloc agrees with the examiner’s characterization of the disclaimed inputs as
not specific to the user. OB at p. 25 (describing “Federal Circuit’s observation that [the licensee
unique ID] cannot be derived solely from” “information ‘specific to the computer or
independently generated by the computer’”) (emphasis in original). Given this basic agreement
regarding the disclaimed claim scope, the only reason Uniloc would oppose instructing the jury
on the disclaimer is that Uniloc intends to do exactly what the doctrine of prosecution disclaimer
forbids.
The Court should inform the jury (1) that a licensee unique ID or licensee unique ID
generating means requires at least one input that is associated with a licensee and (2) that certain
inputs are not associated with a licensee.

18

3.

An Input That Is “Unique to a Licensee” Is Required to Output a Licensee
Unique ID.

The output of a local or remote licensee unique ID generating means cannot be a licensee
unique ID unless an input to the generating means is unique to a licensee. Each of the Federal
Circuit, the Examiner during reexamination, and Uniloc has recognized that a licensee unique ID
can only be generated from particular kinds of inputs to the generating means.
In Uniloc USA, Inc. v. Microsoft Corp., 290 Fed. Appx. 337 (Fed. Cir. 2008) (“Uniloc
I”), the Federal Circuit affirmed the construction of licensee unique ID as “a unique identifier
associated with a licensee.” Uniloc I, 290 Fed. Appx. at 344. As Uniloc recognizes in its brief,
the Federal Circuit went on to state that inputs that are solely platform-related cannot be used to
output a licensee unique ID: “Microsoft is, however, correct that the licensee unique ID cannot
be based solely on platform-related user information.” Id. at 343. Thus, at least some “nonplatform-related unique user information [is] needed to generate the [licensee unique ID].” Id. at
344.
During reexamination, Uniloc relied on the Federal Circuit’s construction in Uniloc I to
argue that “there must be some input to the means for generating the claimed ‘licensee unique
ID’ that characterizes the intended user.” Exhibit 4 (Reply to Second Office Action, filed
Mar. 18, 2011), at pp. 14-15 (UNI075201-202). Uniloc went on to rely on both the plain
language of the claims and the specification of the ’216 patent to support its argument that an
input that is unique to a licensee must be used to generate a licensee unique ID:
The claim term on its face suggests that the ID be generated with some input that
is unique to an intended licensee. … That is, there must be some input to the
generating means capable of making the resulting “licensee unique ID”
uniquely associated with an intended licensee.
The specification is also clear in this regard—the “licensee unique ID” must be
generated from some information that is unique to the intended licensee. … To
generate a licensee unique ID, there must therefore be some input into the
19

generating means that is uniquely associated with the intended licensee. Absent
such input, the ID could not be uniquely associated with an intended licensee.
Id. at p. 19 (UNI075206); see also Ex Parte Reexamination Interview Summary, mailed on
Nov. 19, 201010 at slide 26 (UNI075062) (quoting ’216 patent specification stating that the
algorithm provides a unique registration number if the inputs to the algorithm are unique and
stating that information unique to the user is passed through the algorithm) (“Interview
Summary”).
In view of Uniloc’s clear disclaimer of any ID generated without an input unique to the
intended licensee, Uniloc’s opening brief contains two statements that are demonstrably wrong.
First, the Federal Circuit has not “said that hash values produced by an MD5 hash algorithm
satisfy the licensee unique ID requirement.” See OB at p. 23. To the contrary, the Uniloc I
decision expressly holds that an MD5 hash algorithm that receives solely platform-related user
information cannot generate a licensee unique ID. 290 Fed.Appx. at 343. Second, Defendants’
proposed disclaimer does not erroneously limit the information which can be used to generate a
licensee unique ID. See OB at p. 14. As set forth above, Uniloc itself argued during the
reexamination – extensively and unequivocally – that “information that is unique to the intended
licensee” must be used to generate a licensee unique ID.
4.

The Inputs Disclosed by Hellman Cannot Be Used to Output a Licensee
Unique ID.

Consistent with its arguments that a licensee unique ID requires an input that is unique to
the user, Uniloc’s primary argument for distinguishing the ’216 patent over Hellman during the
reexamination was that none of Hellman’s inputs is unique to a user. This disclaimer of claim

10

A copy of which is submitted herewith as Exhibit 7.

20

scope is broader than the claim scope at issue in the Microsoft litigation, and the Court should
address this issue on claim construction.
In Uniloc II, the Federal Circuit analyzed the ’216 patent’s validity over the Hellman
reference. Hellman discloses a system “which generates an authorization code from the
following inputs: ‘a secret key identifier of the computer embodied in the hardware (SK), a
random or nonrepeating number (R), the serial number, the software package name (H), the
number of uses (N), and user billing information.’” Uniloc II, 632 F.3d at 1322 (citation
omitted).
Microsoft argued that Hellman disclosed a licensee unique ID because SK and R were
associated with the user. Id. Conversely, Uniloc argued that SK and R were platform-related
because they were generated by the user’s computer. Id. The Federal Circuit agreed with Uniloc
and concluded that because SK and R were generated by the user’s computer, these inputs
identified the machine rather than the user. Id. at 1323. In addition, the court stated: “The ‘user
billing information’ in [Hellman] is not an input into the hash function and is thus irrelevant in
determining whether [Hellman] discloses the ‘licensee unique ID’ and ‘licensee unique ID
generating means’ elements of the ’216 patent.” Id. at 1322 n.3. The Federal Circuit did not
address whether the software package name (H) or the number of uses (N) were sufficiently
associated with the user to be used to generate a licensee unique ID.
During the reexamination, however, Uniloc made abundantly clear that none of the inputs
disclosed in Hellman identified a user and that none of them could be used to generate a licensee
unique ID. From the very first examiner interview, Uniloc argued that the main difference
between the ’216 patent and the cited prior art is that the prior art did not disclose a licensee
unique ID “based on information unique to the user.” Exhibit 7 (Interview Summary) at slide 22

21

(UNI075058); see also id. at slide 33 (UNI075069) (titled “Hellman Does Not Disclose a
Licensee Unique ID” (emphasis in original) and quoting Professor Hellman’s trial testimony that
Hellman reference does not disclose use of user information). Slide 34 from the Interview
Summary, shown below, clearly articulates Uniloc’s arguments that none of inputs to Hellman’s
cryptographic function are associated with the licensee:

See also id. at slide 35 (UNI075071).
In its response to the first office action rejecting all claims of the ’216 patent in light of
Hellman and Grundy, Uniloc repeatedly asserted that Hellman did not disclose a “unique
identifier that is associated with a licensee”:
Rather than describe any unique identifier that is associated with an intended
licensee, Hellman instead describes a “method and apparatus in which use of the
software can be authorized for a particular base unit a specific number of times.”
Exhibit 3 (Reply to First Office Action, filed Nov. 29, 2010), p. 17 (UNI075102) (quoting
Hellman 4:38-40).

22

As described more fully below, the “request” and “authorization” are based upon
information regarding the desired software program to be authorized, the number
of uses the software package is to be authorized, a non-unique random number,
and a serial number unique to the computer base unit. Therefore, Hellman fails to
teach or suggest a unique identifier that is associated with a licensee.
Id., p. 18 (UNI075103).
However, as discussed next, none of the input signals to Hellman's cryptographic
function generator 38 (or 23) – namely, K (or SK), N, R and H – are unique to a
licensee and therefore cannot disclose the “local licensee unique ID” of claim 1.
Id., p. 21 (UNI075106).
Uniloc went on to describe each of Hellman’s inputs and explain why each input was not
uniquely associated with a user. Thus, in addition to the base unit (K) and the random number
(R) discussed by the Federal Circuit, none of Hellman’s inputs can be used to generate a licensee
unique ID.
Nor are inputs H [sic N], R or H. Hellman discloses that the next input “N” is
“the number of additional uses of software requested.” Like K, N is not
uniquely associated with an intended licensee. The next input “R” is “a random
number.” A random number is not uniquely associated with an intended licensee.
The next input “H” is “used as an ‘abbreviation’ or name for describing the
software package 21,” where “any two software packages with the same H
value are considered equivalent.” (Hellman, 5:65 - 6:45.) Input “H,” like N
and R, is also not uniquely associated with an intended licensee.
In sum, the signals representing K, N, R, and H are applied as inputs to
cryptographic function generator 38 which generates a check value C as an output
signal. None of these signals are uniquely associated with the licensee and the
resulting value C therefore cannot be equated to the claimed “licensee unique
ID” of independent claim 1. (Rosenblatt Dec., ¶¶ 36-47.)
Id., pp. 22-23 (UNI075107-108).
Uniloc’s discussion of the Secret Key (SK) in the remote cryptographic function
generator is particularly instructive:
The remaining input signal, SK, is “obtained from authorization and billing unit’s
table of serial numbers and secret keys.” (Hellman 7:1-2.) SK is a base unit’s
secret key where “[a]uthorization and billing unit 13 contains a memory 18
having a table of serial numbers and secret keys which allows authorization
23

and billing unit 13 to determine a based unit’s secret key, SK, from knowledge
of the base unit's public serial number.” (See, Hellman 6:19-21.) (See,
Rosenblatt Dec., ¶ 38.) SK is therefore not uniquely associated with an intended
licensee.
Id., p. 24 (UNI075109). Thus, even though the vendor associates the base unit serial number
with the secret key in a table on the remote authorization and billing unit, this secret key is not
uniquely associated with a user.
In its response to the second office action, Uniloc continued to distinguish Hellman on
the grounds that each of its inputs, including the number of software uses requested (N) and the
software package name (H), is not uniquely associated with the user.
Nor is any user specific information input to Hellman’s cryptographic function
generators that generate A and C. ([See, Hellman FIG. 2; 6:16-30; 7:6-13; FIG. 7;
and 10:14-32.]) Indeed, Hellman explicitly states that authorization A is not
associated with a user, but rather is base unit (e.g., a personal computer)
specific. (Hellman, 12:1-9.)
Exhibit 4 (Reply to Second Office Action, filed Mar. 18, 2011), p. 11 (UNI075198).
Hellman’s main deficiency [is] that it does not use any information uniquely
associated with an intended licensee to generate its authorization A (or check
value C).
Id., p. 12 (UNI075199).
Hellman’s cryptographic function generator receives no input that is uniquely
associated with the intended licensee. (Rosenblatt, ¶¶ 38-39.) Hellman’s
authorization A and check value C are limited to identification of the base unit
or the platform on which the software is to be run. (Hellman, 12:5-8.)
Id., p. 19-20 (UNI075206-207).
[T]he billing information is not used to generate the authorization and check
values (A and C, respectively) in Hellman.
...
There is no input into Hellman’s cryptographic function that is uniquely
associated with an intended licensee. (Rosenblatt, ¶¶ 38-39.)
Id., p. 20 (UNI075207).
24

As shown in the excerpts above, Uniloc relied on the Declaration of William R.
Rosenblatt under 37 C.F.R. §1.132, filed Nov. 29, 2010, to distinguish Hellman. Mr. Rosenblatt
also concluded that the hash function disclosed in Hellman could not generate a licensee unique
ID because none of the Hellman inputs to the hash function is unique to a licensee.
38. First, regarding Hellman and “licensee ID generation”: the process in
Hellman cited by the examiner above shows that the “check value C” (Hellman at
10: 17), which the Examiner equates to LUID, is generated from four inputs,
designated as K, N, R, and H. Of these: K is a key to a cryptographic function,
which is an indicium of the computer on which the software is intended to be run.
N is the number of usages of the software requested by the user (see Hellman at
5:65-66); R is a random number (Hellman at 5:66); H is an indicium of the
software package being authorized for use (Hellman at 6:31-35), which is
computed by means of a hash function. A hash function produces a value that
serves as a mathematical “shorthand” for some data that has properties described
appropriately in Hellman at 6:38-61, including that it is efficient to calculate and
store.
39. None of these four inputs is an indicium of the licensee of the software, i.e.,
the user intending to run the software on the computer. Therefore Hellman does
not teach “licensee ID generation.”
Declaration of William R. Rosenblatt under 37 C.F.R. §1.132,11 filed Nov. 29, 2010, ¶¶ 38, 39
(UNI076172) (emphasis in original).
5.

The NIIRC Appropriately Articulates the Scope of Uniloc’s Disclaimer.

The Examiner’s reliance on Uniloc’s disclaimers during reexamination is important
intrinsic evidence for construing the scope of the claims of the ’216 patent. See ACCO Brands,
Inc. v. Micro Sec. Devices, Inc., 346 F.3d 1075, 1078-1079 (Fed. Cir. 2003) (construing claim in
accordance with Reasons for Allowance where Examiner and applicant had same understanding
of claim scope); Gussin v. Nintendo of Am., Inc., 62 F.3d 1433, 1995 WL 460566, at *5 & n.3

11

A copy of which is submitted herewith as Exhibit 8.

25

(Fed. Cir. Aug. 3, 1995) (same).12 In the NIIRC, the examiner synthesized the Federal Circuit’s
construction of licensee unique ID with Uniloc’s reexamination disclaimers.
The Federal Circuit’s construction eschewed IDs generated solely from platform-related
information, such as information generated by the user’s computer, but recognized the possibility
of vendor-supplied information as a permissible input. Uniloc disclaimed the inputs disclosed in
Hellman, as well as any ID generated without inputs that are uniquely associated with a user.
The Court should do likewise and adopt the following disclaimer applicable to all claims:
The licensee unique ID generated by the means recited in each of the claims must
be derived from at least [one] piece of information that is specific to the user, such
as name, billing information, or product information unique to the instantiation
entered by the user. The information cannot be specific to the computer or
independently generated by the computer.
V.

CONCLUSION
For the foregoing reasons Defendants request that their proposed construction be adopted

by the Court and that the Court adopt the proposed disclaimers applicable to all claims.
Dated: September 26, 2011

Respectfully submitted,
/s/ Mark A. Flagel
(with permission by Michael E. Jones)
Michael E. Jones
State Bar No. 10929400
Allen F. Gardner
State Bar No. 24043679
POTTER MINTON
A Professional Corporation
110 N. College, Suite 500 (75702)
Tyler, Texas 75702
[phone]
[phone] (Facsimile)

12

In addition to ACCO Brands, which supports rather than contradicts defendants’ reliance on the NIIRC, Uniloc
asserts that reference to the NIIRC is improper under Inverness Medical Switzerland v. Princeton Biomeditech
Corp., 309 F.3d 1365, 1372-73 (Fed. Cir. 2002). But Inverness says nothing about the general applicability of a
Reasons for Allowance to claim construction. Rather, Inverness rejected the appellee’s reliance on the Reasons for
Allowance because “[t]he examiner’s statement, however, contradicts the appellee’s position.” Id. at 1373.

26

[e-mail]
[e-mail]

Mark A. Flagel
Yury Kapgan
Dale Chang
LATHAM &WATKINS LLP
355 S. Grand Avenue
Los Angeles, CA 90071-1560
Tel: [phone]
Fax: [phone]
[e-mail]
[e-mail]
[e-mail]
Dean G. Dunlavey
LATHAM &WATKINS LLP
650 Town Center Drive, 20th Floor
Costa Mesa, CA 92626-1925
Tel: [phone]
Fax: [phone]
[e-mail]
ATTORNEYS FOR DEFENDANTS AND
COUNTERCLAIM-PLAINTIFFS SYMANTEC
CORPORATION
By: /s/ Charles D. Huston, with permission by
Michael E. Jones
Charles D. Huston
State Bar No. 10328950
Stacy L. Zoern
State Bar No. 24051565
DAFFER MCDANIEL, LLP
700 Lavaca Street, Suite 720
Austin, TX 78701
Tel. [phone]
Fax [phone]
ATTORNEYS FOR PERVASIVE
SOFTWARE INC.
By: /s/ Melissa Richards Smith, with permission by
Michael E. Jones
Melissa Richards Smith
TX Bar No. 24001351
27

GILLAM & SMITH, L.L.P.
303 South Washington Avenue
Marshall, Texas 75670
Telephone: [phone]
Facsimile: [phone]
Email: [e-mail]
MORRISON & FOERSTER LLP
Michael A. Jacobs (CA Bar No. 111664)
425 Market Street
San Francisco, California 94105
Telephone: [phone]
Facsimile: [phone]
E-mail: [e-mail]

MORRISON & FOERSTER LLP
Rudy Y. Kim (CA Bar No. 199426)
Christopher F. Jeu (TX Bar No. 24050823)
755 Page Mill Road
Palo Alto, California 94304
Telephone: [phone]
Facsimile: [phone]
E-mail: [e-mail]
E-mail: [e-mail]
Attorneys for Defendant FILEMAKER, INC

CERTIFICATE OF SERVICE
The undersigned hereby certifies that all counsel of record who are deemed to have
consented to electronic service are being served with a copy of this document via the Court’s
CM/ECF system per Local Rule CV-5(a)(3) on September 26, 2011.

/s/ Michael E. Jones

28