Veracode, Inc. et al v. Appthority, Inc.

Filing 51

Judge Douglas P. Woodlock: MEMORANDUM AND ORDER regarding claim construction entered. (Woodlock, Douglas)

UNITED STATES DISTRICT COURT
DISTRICT OF MASSACHUSETTS
VERACODE, INC., and ROVI
SOLUTIONS CORP.,

)
)
)
)
)
)
)
)
)
)

Plaintiffs,
v.
APPTHORITY, INC.,
Defendant.

CIVIL ACTION NO.
12-10487-DPW

MEMORANDUM AND ORDER
October 9, 2013
Plaintiffs Veracode, Inc. and Rovi Solutions Corp. bring
this action against Defendant Appthority, Inc. for infringement
of two patents for use in analyzing and manipulating computer
code: U.S. Patent No. 5,854,924 (the “‘924 Patent”), and U.S.
Patent No. 7,752,609 (the “‘609 Patent”).

Veracode is the

exclusive licensee of the ‘924 Patent, a “static debugging tool .
. . to detect the presence of program errors and potential
errors” in the machine-code version of a piece of software
without actually running the analyzed software.
Abstract.)

(‘924 Patent,

It also owns the ‘609 Patent, a method of decompiling

machine code, which humans cannot interpret, into a form “that
one of certain skill can analyze.”
57.)

(‘609 Patent, Summary 2:56-

Before me are the parties’ respective briefs regarding the

construction of several claim terms in the patents.
dispute the construction of nine terms:
-1-

The parties

five terms in the ‘924

Patent and four in the ‘609 Patent.

In addition to disagreement

over the precise definition of certain of these terms, the
parties also dispute whether the term “Data Flow Signatures” is
indefinite and whether the preamble to Claim 1 of the ‘924 Patent
is a substantive limitation on the claim or merely prefatory.
I.

BACKGROUND

Veracode is a computer security company, founded in 2006,
providing a cloud-based platform to analyze software applications
for flaws and security risks, as well as remediation services to
help developers fix the flaws in their code.

Similarly,

Veracode’s competitor, Appthority, provides a cloud-based
platform, which became publicly available in 2012 and that
analyzes the enterprise risk for mobile phone applications,
Appthority’s platform focuses on identifying malware and risky
behaviors within applications to determine whether they are safe
for the target user or company.
Software developers write computer programs in the source
code of a particular programming language, such as Java, PHP, or
C++.

Persons of ordinary skill in the art of software

development can easily read and interpret this code, but
computers themselves cannot.

Before a computer can read and

execute the code to run the program, the source code must be
compiled into machine-readable, binary code.
use different binary languages.

Different computers

Developers can translate this
-2-

binary code into a human-readable intermediate form though a
process called disassembly or decompilation.

The intermediate

file is intelligible to humans, but more difficult to interpret
than the original source code.

The intermediate file contains

all the same commands and instructions as the binary code, but in
a human-readable form rather than binary form.

This includes the

control flow - the sequence of instructions in the program - as
well as the data flow - how and when the program reads and writes
data into memory.

Developers can then reverse engineer the

intermediate file to reconstruct or approximate the original
source code.
A.

The Patents
Veracode filed this action on March 16, 2012 - approximately

one month after Appthority’s public launch - alleging
infringement of the two patents in suit: the ‘924 Patent and the
‘609 Patent.

Both Patents relate to software analysis.

The ‘924 Patent, issued in 1998, is a “Static Debugging
Tool.”

(‘924 Patent, Abstract.)

It analyzes the binary version

of a piece of software and, in at least one embodiment, generates
an intermediate file in order to analyze the program for errors
and potential errors without having to actually run the program.
(Id. at 1:64-2:1.)
The ‘609 Patent, issued in 2010, but claiming priority to
2002, is a “Software Analysis Framework” which also generates an
-3-

intermediate file from a program’s binary code.

It “determine[s]

if flaws, security vulnerabilities, or general quality issues
exist in the code” by analyzing the sequence of instructions in
the software as well as the processes for reading and writing
data, generating a symbolic model of these processes, and
comparing them to reference models.
II.

(‘609 Patent, Abstract.)

PRINCIPLES OF CLAIM CONSTRUCTION

The purpose of the claim construction process is “to
determine the meaning and scope of the patent claims that the
plaintiff alleges have been infringed.”

Every Penny Counts,

Inc., v. American Express Co., 563 F.3d 1378, 1381 (Fed. Cir.
2009).

Claim construction is an issue of law “exclusively within

the province of the court.”

Markman v. Westview Instruments,

Inc., 517 U.S. 370, 372, 384 (1996).
A patent must include “one or more claims particularly
pointing out and distinctly claiming the subject matter which the
applicant regards as his invention.”

35 U.S.C. § 112(b).

To

interpret the terms in a claim, “we look to the words of the
claims themselves, the specification, the prosecution history,
and any relevant extrinsic evidence.”

Retractable Technologies,

Inc. v. Becton, Dickinson and Co., 653 F.3d 1296, 1303 (Fed. Cir.
2011).

“As a general rule, claim terms should be given their

ordinary and customary meaning to persons of skill in the art as
of the effective date of the patent application.”

Eon-Net LP v.

Flagstar Bancorp, 653 F.3d 1314, 1320 (Fed. Cir. 2011).
-4-

“[T]he

claims themselves provide substantial guidance as to the meaning
of particular claim terms.”

Abbott Laboratories v. Sandoz, Inc.,

566 F.3d 1282, 1288 (Fed. Cir. 2009)(quoting Phillips v. AWH
Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005)).

“When the ordinary

meaning of claim language as understood by a person of skill in
the art is readily apparent even to lay judges, claim
construction ‘involves little more than the application of the
widely accepted meaning of commonly understood words.’”
Millipore Corp. v. W.L. Gore & Assoc., 750 F. Supp. 2d 253, 264
(D. Mass. 2010) (quoting Phillips, 415 F.3d at 1314).
When terms are ambiguous, the court may consult the
specification to clarify their meaning.

Teleflex, Inc. v. Ficosa

N. Am. Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002).

However, in

consulting the specification, courts must walk a fine line.

We

“must take care not to import limitations into the claims from
the specification.”

Abbott Labs v. Sandoz, Inc., 566 F.3d 1282,

1288 (Fed. Cir. 2009); see also Kara Tech., Inc. v. Stamps.com
Inc., 582 F.3d 1341, 1348 (Fed. Cir. 2009) (“The patentee is
entitled to the full scope of his claims, and we will not limit
him to his preferred embodiment or import a limitation from the
specification into the claims.”).

“[E]ven where a patent

describes only a single embodiment, claims will not be read
restrictively unless the patentee has demonstrated a clear
intention to limit the claim scope . . . .”
-5-

Innova/Pure Water,

Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1117
(Fed. Cir. 2004).
On the other hand, “[a] patent’s specification provides
necessary context for understanding the claims,” and “sometimes
the specification offers practically incontrovertible directions
about claim meaning.”

Abbott Labs, 566 F.3d at 1288.

When a

patent specification
makes clear that the invention does not include a
particular feature, that feature is deemed to be
outside the reach of the claims of the patent, even
though the language of the claims, read without
reference to the specification, might be considered
broad enough to encompass the feature in question.
SciMed Life Sys., Inc. v. Advanced Cardiovascular Sys., Inc., 242
F.3d 1337, 1342 (Fed Cir. 2001).
The prosecution history can also inform claim meaning “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.”

Phillips, 415 F.3d at 1317.

Courts may also consider “extrinsic evidence,” which is
evidence outside of the patent and prosecution history, including
dictionaries.

Id. at 1318.

Although “extrinsic evidence can

help educate the court regarding the field of the invention and
can help the court determine what a person of ordinary skill in
the art would understand the claim terms to mean,” id. at 1319,
it is “less reliable than the patent and its prosecution
-6-

history,” id. at 1318.

Thus, extrinsic evidence is “unlikely to

result in a reliable interpretation of patent claim scope unless
considered in the context of the intrinsic evidence.”

Id. at

1319.
Furthermore, patent law requires that claims be “definite.”
This requirement stems from the language of 35 U.S.C. § 112(b),
which states “[t]he specification shall conclude with one or more
claims particularly pointing out and distinctly claiming the
subject matter which the applicant regards as his invention.”

“A

claim is indefinite if its legal scope is not clear enough that a
person of ordinary skill in the art could determine whether a
particular [product] infringes or not.

Geneva Pharmaceuticals,

Inc. v. GlaxoSmithKline PLC, 349 F.3d 1373, 1384 (Fed Cir. 2003).
A claim is not indefinite merely because it is difficult to
construe.

Rather, a claim is only indefinite if it is so

“insolubly ambiguous” that is it simply “not amenable to
construction.”

Datamize LLC v. Plumtree Software, Inc., 417 F.3d

1342, 1346 (Fed. Cir. 2005).

Even if reasonable minds might

differ regarding the proper construction, the claim will be
definite if it can “can be given any reasonable meaning.”

Id. at

1347; see also Exxon Res. & Eng’g Co. v. United States, 265 F.3d
1371, 1375 (Fed. Cir. 2001).

According to the Federal Circuit,

examples of when a claim may be indefinite include claims
“completely dependent on a person’s subjective opinion,” claims

-7-

without a “proper antecedent basis where such basis is not
otherwise present by implication or the meaning is not reasonably
ascertainable,” and claims that “include[]a numeric limitation
without disclosing which methods of measuring . . . should be
used.”

Halliburton Energy Servs., Inc. v. M-I LLC, 514 F.3d

1244, 1249 (Fed. Cir. 2008).
III.
A.

CLAIM CONSTRUCTION

The ‘924 Patent
1. Preamble - “Debugging”
Appthority argues that the preamble to Claim 1 is limiting.

Veracode disagrees.

I find that the preamble merely provides the

context and purpose for the claim and therefore does not
constitute a substantive limitation.
The traditional rule is that preamble language does not act
as a limitation unless it is “necessary to give life, meaning,
and vitality to the claim.”
(C.C.P.A. 1951).

Kropa v. Robie, 187 F.2d 150, 152

When limitations in the body of the claim “rely

upon and derive antecedent basis from the preamble, the preamble
may act as a necessary component of the claimed invention,” but
“if the body of the claim sets out the complete invention, the
mythed language of the preamble may be superfluous.”

Eaton Corp.

v. Rockwell Int’l Corp., 323 F.3d 1332 (Fed. Cir. 2003) (quoting
Schumer v. Lab. Computer Sys. Inc., 308 F.3d 1304, 1310 (Fed.
Cir. 2002).

In other words, if the body of the claim recites a
-8-

“structurally complete invention” without reference to the
preamble, the preamble does not limit the claim.

Catalina

Marketing Int’l, Inc. v. Coolsavings.com, Inc., 289 F.3d 801, 808
(Fed. Cir. 2002).

The body of Claim 1 in the ‘924 Patent recites

a structurally complete invention.
Without the preamble, Claim 1 reads:
an analyzer for causing die [sic] computer to
statically analyze a representation of the binary
program file in order to detect the presence of program
errors or potential program errors in the
representation of the binary program file without
executing the binary program file, wherein the
representation of the binary program file is an
intermediate file; and
an output arrangement for causing the computer to
output an error list of the errors or potential errors
detected by the analyzer.
(‘924 Patent, 17:13-22.)

This language presents the complete

idea without any need to reference the preamble.

It does not

refer to any antecedent or idea defined only in the preamble, nor
does it lack clarity in the absence of the preamble.
is straightforward:

The claim

an analyzer that detects errors in a static,

intermediate representation of binary code and outputs those
errors into a list.

All of this information appears is the

language of the body of claim itself.
The preamble merely adds that Claim 1 describes
a static debugging tool for use with a computer and for
debugging a binary program file without requiring the
execution of the binary program file in order to detect
the presence of program errors and potential program
errors.
-9-

(Id. at 17:9-13.)
Appthority argues that the term “debugging” is “necessary to
give life, meaning, and vitality to the claim,”

Kropa, 187 F.2d

at 152, and, therefore, that it substantively limits the claims
and that the court must construe it.

I disagree.

Even if the

body of Claim 1 did not clearly indicate to a person of ordinary
skill in the art that this analyzer constitutes a “debugging
tool,” (Id. at 17:9) - a dubious proposition in light of the
claim language stating that the analyzer “detects the presence of
program errors or potential program errors,” (Id. at 17:15-16.) the issue is ancillary.

The language of the body of the claim

describes what the patent claims:

an analyzer to find errors in

static, intermediate representations of binary code.

That the

preamble describes such an analyzer as a “debugging tool” neither
adds to nor takes away from what the patent claims.
shorthand.

It is merely

It succinctly describes the purpose of the analyzer,

but descriptions of purpose in a preamble are not limiting.
Catalina Mktg. Int’l, 289 F.3d at 808 (“[A] preamble is not
limiting where a patentee . . . uses the preamble only to state a
purpose or intended use for the invention.” (internal quotations
omitted)).
Unlike in Vizio, Inc. v. Int’l Trade Comm’n and Griffin v.
Bertina, where the Federal Circuit held that the phrases “for
decoding” and “for diagnosis” were substantive limitations rather

-10-

than mere statements of purpose, revealing the errors or
potential errors in a binary file has more directly practical
use.

In Vizio and Griffin, the Federal Circuit held the

preambles to be limiting because, without those descriptions, the
claimed processes would be “mere[] academic exercises,” Vizio,
605 F.3d 1330, 1341 (Fed. Cir. 2010); Griffin, 285 F.3d 1029,
1033 (Fed. Cir. 2002).

The list of errors and potential errors

that the analyzer described in Claim 1 produces is analogous to
the phrase “for diagnosis” in Griffin, not the underlying, purely
academic “obtaining nucleic acid and assaying for a point
mutation.”

Griffin, 285 F.3d at 1033.

The list of errors

essentially is a diagnosis for what is wrong with the analyzed
software.

It does not require any further description of purpose

to give life, meaning and vitality to the claim.

The described

list of errors in the ‘924 Patent is useful, as in the Griffin
patent, “for diagnosis;” in this case, for diagnosis of the
analyzed program.

Therefore the phrase “debugging tool” merely

describes the purpose of the structurally complete analyzer and
is not necessary to give life or purpose to the claim as the
phrases “for decoding” and “for diagnosis” were in Vizio and
Griffin.
Defendant’s argument that the body of Claim 1 is not
structurally complete because it does not describe any specifics
about the way in which the analyzer works is little more than

-11-

distraction.

Defendant’s argument ignores the 23 other claims in

the Patent - including four dependent claims specifically
addressed to Claim 1 - that describe the analyzer in greater
detail.

If courts required each individual claim in a patent to

set out every detail of the entire patent in order to define a
structurally complete invention, no valid patent could ever have
more than a single, unwieldy claim.

I find that the preamble

does not limit Claim 1, and therefore decline to construe the
term “debugging.”
2. “Program Errors”
Appthority argues that the term “Program Errors” means
“unintended programming mistakes inconsistent with the program’s
intended design.”

It also offers the alternative, “a value or

condition that is not consistent with the true, specified, or
expected value or condition.” Veracode argues that the term’s
meaning is clear and does not require construction.

However

Veracode also contends that the plain meaning of “Program Errors”
includes intentional errors that may be consistent with the
intended design of the analyzed program.

While this is a

potentially appropriate construction of the term “error,” it is
not likely to be intuitive to a jury, nor would declining to
construe the term resolve the crux of the disputes between the
parties:

whether an error must be unintentional and whether it

must be contrary to the program’s intended design.

-12-

The term

requires construction to resolve this dispute and to clarify the
term’s meaning for a jury.

See O2 Micro Int’l v. Beyond

Innovation Tech., 521 F.3d 1351, 1362-63 (Fed. Cir. 2008) (“When
the parties present a fundamental dispute regarding the scope of
a claim term, it is the court’s duty to resolve it.”).
The word “error” does not necessarily imply “mistake.”
Although these two words have overlapping definitions, they are
not entirely synonymous.
cannot.
“error.”

An error can be intentional, a mistake

The ‘924 Patent does not explicitly define the word
Therefore, recourse to a technical dictionary for the

relevant art may be appropriate if that definition is consistent
with the Patent’s use of the term.

MIT v. Abacus Software, 462

F.3d 1344, 1351 (Fed Cir. 2006) (holding that “it is appropriate
for us to look to dictionary definitions of the terms” where “the
specification does not define the term” and “the most that can be
said is that the specification is not inconsistent” with the
proposed constructions by the parties).
The Microsoft Press Computer Dictionary from the time the
‘924 Patent issued defines “error” as “[a] value or condition
that is not consistent with the true, specified, or expected
value or condition.

In computers, an error results when an event

does not occur as expected or when impossible or illegal
maneuvers are attempted.”

(Def.’s Opening Br., Ex. A at 179.)

An “error” can be either an unexpected occurrence or the result

-13-

of an impossible or illegal maneuver.

Thus, an error is not

necessarily a mistake, nor is it necessarily contrary to the
purpose of a program.
There are a variety of conceivable reasons why a software
developer might purposefully include a function that would return
an impossibility or conduct an illegal maneuver in order to
advance the purposes of the program.

Indeed, the definition:

“the result of an impossible or illegal maneuver” is consistent
with the way in which the specification uses the term “error.”
The specification provides a variety of examples of the kinds of
errors that the ‘924 Patent is designed to detect.

These include

“uninitialized memory, array bounds violations, accesses outside
of allocated memory, inconsistent argument types or returns
between calls and called functions, . . . invalid references to
automatic memory . . ., accessing freed memory,” (‘924 Patent at
9:3-14), as well as “potential return of an automatic address,”
(Id. at 9:38-39), and “function parameters that are out of
bounds, memory access errors, and potential invalid operands for
arithmetic operations such as dividing by zero,” (Id. at 16:3537).

Some of these examples are necessarily unintentional.

Others may be intentional and designed to further some purpose of
the program.

Many of the examples of errors listed in the

specification - such as accessing invalid memory and array bounds
violations - are useful tools for exploitation or subversion.

-14-

For instance, Plaintiff’s expert, Aviel Rubin, describes how some
software developers might purposefully include an array bounds
violation in order to maintain a “backdoor” into the program.
Intent cannot logically be a limitation on the patent’s use of
the term “error” where the specification itself uses the term to
mean errors that can be either intentional or unintentional.
It is not relevant for purposes of claim construction that
Rubin’s example of a potentially intentional error also
potentially constitutes malicious code.

The relevance is that

the specification includes, as examples of potential errors that
the patented analyzer detects, certain errors that might be
either intentional or unintentional.

The ‘924 Patent does not

detect only unintentional errors contrary to the purposes of the
program - some errors it detects may be intentional.

Nor does it

specifically detect malicious code - some of the errors it
detects are, of necessity, mistakes that are neither malicious
nor intentional.

Instead, the common element in all of the

errors the ‘924 Patent’s specification lists is that they are all
the result of an illegal or impossible maneuvers in the code.
Plaintiff’s argument - that Appthority lists many examples
of errors set out in the specification that must be unintentional
whereas Veracode lists only one or two examples of errors in the
specification that can be intentional - is perplexing.

If even a

single example of an error listed in the specification can be

-15-

intentional, then, as a matter of logic, the term is not
necessarily limited to unintentional errors.

Because the Patent

does not limit this term to unintentional errors, I also reject
Veracode’s amended proposed construction suggested in
supplementary briefing:

“a value or condition that is not

consistent with the true, specified, or expected value or
condition.”

This portion of the MS Computer Dictionary

definition focuses on the unexpected nature of certain values or
conditions, which is not a proper limitation on the scope of the
term “Program Error” as used in the ‘924 Patent.

The common

factor in each of the listed examples of errors in the
specification is that they are the result of “impossible or
illegal maneuvers.”

I am mindful, however, that the infringement

contentions in this case involve the ability of each party’s
software to detect nefarious, illegal activity - activity that is
illegal because the law prohibits it.

The phrase “the result of

an illegal or impossible maneuver,” by contrast, uses the word
“illegal” differently - to mean invalid.
I construe “Program Errors” to mean “the result of an
invalid or impossible maneuver.”
3. “Intermediate File”
The parties agree that the term “Intermediate File” means a
“representation of the binary file.”

However, the parties

dispute (a) whether it must be machine independent, meaning that

-16-

the code is not unique to the processor’s specific binary
language, and (b) whether it is, by definition, not source code.
Appthority proposes the construction “machine independent
representation of the binary file.”

In its supplementary

briefing, Appthority also suggests the alternative, “a
representation of the binary file for analysis by the analyzer.”
Veracode proposes the construction “a representation of the
binary file that is not source code.”
a. Machine Independent
The “Independent File” is not necessarily machine
independent.

The Patent claims repeatedly describe the

intermediate file as a “machine independent, intermediate file”
However, machine independence is not an inherent characteristic
of the Patent’s use of the term “Intermediate File.”
Claim 1 describes a debugging tool that analyzes a
representation of the binary program file “wherein the
representation of the binary program file is an intermediate
file.”

(‘924 Patent, 17:18-19.)

Claim 2, which depends on Claim

1, states that a decompiler causes the computer to “translate the
binary program file into an intermediate, machine independent
program file.”

(Id. at 17:26-28.)

Similarly, Claim 13 describes a method of detecting program
errors “wherein the representation of the binary program includes
an intermediate file that represents the binary program file and

-17-

includes the flow paths and flow structure associated with the
binary program.”

(Id. at 18:19-23.)

Claim 15, which depends on

Claim 13, claims “a method according to Claim 13 further
comprising the step of decompiling the binary program file to
create a machine independent, intermediate file to be analyzed in
the analyzing step.”

(Id. at 18: 37-40.)

Claims 17 and 18 also

present the same relationship.
Under principles of claim differentiation, Claims 1 and 2
must be distinct from one another, as must Claims 13 and 15.
See Comark Comm’ns v. Harris Corp., 156 F.3d 1182, 1187 (Fed.
Cir. 1998)(the doctrine of claim differentiation “create[s] a
presumption that each claim in a patent has a different scope.”).
Furthermore, The independent claims - Claims 1 and 13 - must be
broader than the dependent claims - Claims 2 and 15.

Am. Medical

Sys., Inc. v. Biolitec, Inc., 618 F.3d 1354, 1360 (Fed. Cir.
2010) (“Under the doctrine of claim differentiation, those
dependent claims give rise to a presumption that the broader
independent claims are not confined to that range.”).
Appthority argues that Claims 1 and 2 are distinguishable on
bases other than the machine independence of the intermediate
file described in Claim 2.

For instance, Claim 2 recites a

“decompiler” not present in Claim 1.

Claims 13 and 15 are

susceptible to the same distinction.

Claim 13 states that the

claimed “method of detecting program errors” includes analyzing

-18-

an intermediate file, which is a representation of the binary
file.

Claim 15 recites a further step of decompiling the binary

file into a machine independent intermediate file.

The same is

also true of Claim 18, which uses the phrase “machine independent
program file” and which depends on Claim 17.

Although the

doctrine of claim differentiation may be satisfied by the single,
narrow distinction of decompilation, see Mantech Envr. Corp. v.
Hudson Envr. Servs., 152 F.3d 1368, 1376 (Fed. Cir. 1998), the
Patent’s consistent use of the phrase “machine independent” only
in dependent claims and specific embodiments makes clear that the
Patent intends that the term “Intermediate File” should not be
limited to machine independence.

Thus, although the doctrine of

claim differentiation does not apply in its strictest sense
because there are two grounds on which to distinguish Claim 2
from Claim 1, Claim 15 from Claim 13, and Claim 18 from Claim 17,
it remains instructive in illuminating the intended scope of the
term “Intermediate File.”
The phrase “machine independent” appears nine times
throughout the ‘924 Patent.

However, it neither appears in a

high-level description of what the Patent claims, nor does it
appear in any independent claim.

It first appears in the

“Summary of Invention section” in the description of a preferred
embodiment.

(‘924 Patent at 1:68.)

However, this immediately

follows a broader description of what the patent claims,

-19-

including an explanation that the invention analyzes a
“representation of the binary file.”

(Id. at 1:50-63.)

It next

appears several times throughout the section of the Patent
entitled “Detailed Description of the Preferred Embodiments,”
(See id. at 3:61, 63; 4:63; 6:1, 10), however, the Federal
Circuit has repeatedly asserted that reading limitations from
particular embodiments into the claims is the “cardinal sin” of
claim construction.

See Phillips v. AWH Corp., 415 F.3d 1303,

1319-20 (Fed. Cir. 2005) (citing SciMed Life Sys. v. Adv.
Cardiovascular Sys., Inc., 242 F.3d 1337, 1340 (Fed. Cir. 2001)).
Finally, it appears three times in the claims themselves, in
Claim 2, Claim 15, and Claim 18.

However, each of these claims

depends on an earlier independent claim, which also uses the
phrase “Intermediate File,” but does not include the limitation
“machine independent.”
The independent claims all use the term “Intermediate File,”
while their respective dependent claims use the more specific
phrase “machine independent intermediate file.”

Because the

doctrine of claim differentiation suggests that an independent
claim should be broader than its dependent, and because of the
direct connection between the use of the broad phrase
“Intermediate file” in the independent claims and the use of the
more specific phrase “machine independent intermediate file” in
the dependent claims, I find that the independent claims

-20-

contemplate intermediate files that are not necessarily machine
independent despite the fact that there may also be other grounds
to differentiate the claims.

See Phillips, 415 F.3d at 1315

(“[T]he presence of a dependent claim that adds a particular
limitation gives rise to a presumption that the limitation in
question is not present in the independent claim.”).
b. Not Source Code
By the very nature of the term “Intermediate File,” it
cannot be source code.

Nor can it be binary code.

It is

“intermediate” because it is between the binary file and the
source code.

This meaning of the term “intermediate” is well

understood by those of ordinary skill in the art of software
development.

The Microsoft Press Computer Dictionary from the

time period when the ‘924 Patent issued defines “intermediate
language” as “[a] computer language used as an intermediate step
between the original source language, usually a high-level
language, and the target language, usually machine code.”

By

extension, an “Intermediate File” is a file, which is written in
the intermediate language, containing a representation of the
binary program file, which was written in binary code.
This is equally clear from the ‘924 Patent itself.

In

describing the background of the invention, the Patent
distinguishes the prior art, stating, “[p]resently, virtually all
debugging tools do their debugging at the source code level.”

-21-

(‘924 Patent at 16-18.)

Then, in describing how the invention

improves on this prior art, the Patent summary states that, “[i]n
one embodiment of the present invention . . . an intermediate
machine independent program file . . . serves as the
representation of the binary program file to be analyzed . . . .”
(Id. at 65-69.)

As one of the stated improvements over the prior

art, the described invention analyzes the intermediate file
rather than source code.

It cannot be the source code because

the stated improvement from the prior art is that the ‘924 Patent
can analyze a program without the effort of translating it fully
back into source code.

The intermediate file also cannot be the

binary program file since it is a representation of that file.
Rather the “Intermediate File” is a representation of the
program’s code written in a higher-level language than binary,
machine code, but in a lower-level language than full source
code.
Appthority’s position - that the intermediate file can be
source code and that it is only intermediate in the sense that is
a stepping stone in the debugging process - is a distinction
without a difference.

Its description of the intermediate file

as a stepping stone between the binary program file and the
ultimate list of errors is entirely consistent with Veracode’s
proposed construction.

Appthority has not articulated any way in

which the intermediate file could be considered a stepping stone

-22-

in the debugging analysis other than as an intermediate language
between binary and source code.

Thus, its alternative proposed

construction, “a representation of the binary file for analysis
by the analyzer,” obscures rather than clarifies.

It does

nothing to resolve the parties dispute regarding source code and
would therefore be an inappropriate construction.
Appthority also argues that the “Patent makes no statement
at all about what sort of code the intermediate file contains
(binary vs. source),” but this argument simply assumes what it
seeks to prove:

that the intermediate file is intermediate in

some way other than the kind of code it contains.

I therefore

reject Defendants argument, and ultimately find that the
intermediate file is neither source code nor binary code.
I construe “Intermediate File” to mean “a representation of
the binary file that is neither in binary code nor source code.”
4. “Decompiler”
The parties’ disputes regarding construction of the term
“Decompiler” echo their previous disputes over the meaning of
“Intermediate File.”

Appthority proposes the construction,

“[Tool for] converting binary code to machine independent, highlevel language source code”

Veracode proposes the construction,

“Software that translates the binary program file into an
intermediate, machine independent program file.”

I find that the

term “Decompiler,” as used in the ‘924 Patent does not generate

-23-

high-level source code; the code it generates is machine
independent.
a. High-Level Language Source Code
Claim 2 recites a “decompiler for causing the computer to
decompile the binary program file and translate the binary
program file into an intermediate, machine independent program
file.”

(‘924 Patent at 17:25-28.)

As discussed above, see

Section III(A)(3)(b), the intermediate file that this decompiler
generates is neither source code nor binary code.

I reject

Appthority’s attempt to graft the term “source code” onto
“Decompiler” for the same reasons I rejected its attempt to do
the same to the term “Intermediate File.”
Appthority’s citation to the MS Computer Dictionary to
support its proposed construction is unavailing.

Although the MS

Computer Dictionary defines “Decompiler” as “a program that
attempts to generate high-level source code from assembly
language code or machine code,” that dictionary definition
contradicts the way in which the Patent uses the term, and the
intrinsic evidence of the Patent controls over the extrinsic
evidence of a dictionary definition.

See W.E. Hall Co. v.

Atlanta Corrugating, LLC, 370 F.3d 1343, 1350 (Fed. Cir. 2004)
(“While dictionaries may be used to ascertain the plain and
ordinary meaning of claim terms, the intrinsic record is used to
resolve ambiguity in claim language or, where it is clear, trump

-24-

inconsistent dictionary definitions.”).

A Patentee is free to

use or define a term in a way that does not necessarily comport
with the conventional meaning of that term.

See Honeywell Int’l,

Inc. v. Universal Avionics Sys. Corp., 493 F.3d 1358, 1361 (Fed.
Cir. 2007)(“When a patentee defines a claim term, the patentee’s
definition governs, even if it is contrary to the conventional
meaning of the term.”).

Indeed, the very nature of Patents,

often requires defining new terms or reconsidering the meaning of
existing terms in order to capture a new method or device not yet
understood by the prior art.

The claims in the ‘924 Patent that

use the term “Decompiler” state that the purpose of decompilation
is to create an intermediate file, and any appropriate
construction of that term must comport with the way the patent
uses it.

(See ‘924 Patent, Claims 2, 15, 16, 18.)

In its supplementary brief, Appthority argues that this
Court’s construction of Decompiler in combination with its
construction of Intermediate File would have the unintended
effect of excluding source code from the meaning of the
Decompiler, contradicting the ordinary industry meaning of the
term.

To the contrary, this exclusion is conscious, intentional,

and necessary in light of the language of the specification.
As discussed above, the ‘924 Patent does not use the word
“Decompiler” according to the industry-standard definition of a
tool to translate low-level machine code into high-level source

-25-

code.

Rather, the Patent uses the term Decompiler more

generically as a tool that translates a lower-level language into
a higher-level form:
intermediate file.

in this case, from machine code into an

The Patent’s specific use of a term - and not

the industry standard understanding - controls the appropriate
construction of any term.
1361.

See Honeywell Int’l, Inc., 493 F.3d at

The intrinsic evidence - the language of the patent - uses

the term Decompiler in a way that is inconsistent with
translation into source code and therefore Appthority’s reliance
on contrary extrinsic evidence - industry dictionaries and
understanding - is misplaced.

See id.

Appthority also argues that Veracode’s proposed construction
renders a step of the claimed decompilation process superfluous.
This cannot be reconciled with either the plain claim language or
Appthority’s own proposed construction.

Claim 2 recites “a

decompiler for causing the computer to decompile the binary
program file and translate [it] into an intermediate, machine
independent program file.”

(Id. at 17:25-28 (emphasis added).)

Appthority argues that the word “and” indicates that
“decompiling” and “translating” are two separate and distinct
steps.

However, reading the claims in their entirety, it is

clear that the Patent uses the word “and” to signify that the
language that follows defines “decompile.”

For instance, Claim

15 states a “method . . . of decompiling the binary program file

-26-

to create a machine independent, intermediate file to be analyzed
in the analyzing step,” only reciting a single step.
18:37-40 (emphasis added).)

(Id. at

The phrases “a decompiler for

causing” and “decompiling . . . to create” equate the decompiler
or decompilation process with the creation of the intermediate
file, essentially defining “Decompiler” as the tool for executing
that process.

Thus, reading Claim 15 and Claim 2 together, the

meaning of the word “and” in Claim 2 becomes clear.

It equates

decompiling the binary program file with translating it into the
intermediate file.

It does not signify two separate steps, as

Appthority contends.

In fact, Appthority’s proposed construction

of “Decompiler” would render the second half of the language in
Claim 15 redundant.

Furthermore, Appthority undercuts its own

argument that Claim 2 must recite two steps because Appthority
itself proposes one-step construction of “Decompiler.”

Thus

Appthority’s argument runs contrary to the claim language itself,
and runs afoul of the “‘bedrock principle’ of patent law that
‘the claims of a patent define the invention to which the
patentee is entitled the right to exclude.’”

Phillips, 415 F.3d

at 1312 (quoting Innova/Pure Water, Inc. v. Safari Water
Filtration Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)).
Because the Patent and the MS Dictionary itself make clear
that the intermediate file is not source code, see Section
III(A)(3)(b), the term “Decompiler,” as used in the ‘924 Patent,

-27-

is inconsistent with translation into high-level source code.

I

therefore decline Appthority’s invitation to graft the phrase
“source code” onto the meaning of “Decompiler.”
b. Machine Independent
Both proposed constructions include the limitation that the
Decompiler creates a machine independent program file.
with this aspect of the construction.

I agree

Unlike the term

“Intermediate File,” which appears in the Patent’s independent
claims, the term “Decompiler” or “decompile” appears in the
dependent claims alongside the explicit “machine independent”
limitation. (See ‘924 Patent, Claims 2, 15, 18.)1

“Decompiling”

appears in Claim 16, but Claim 16 depends on Claim 15, which
itself describes the “Intermediate File” as machine independent,
and as a dependent claim, Claim 16 incorporates the limitations
of the independent claim on which it depends.

Thus, the Patent

claims themselves indicate that machine independence is
necessarily a limitation on the term “Decompiler,” as the parties
themselves concede.
I construe “Decompiler” as “a tool for translating the
binary program file into an intermediate, machine independent
program file.”

1

“Decompiled” also appears in Claim 3, but Claim 3 does not
discuss the “Intermediate File,” and so does not counsel in favor
or against limiting the decompiler to producing machine
independent products.
-28-

5. “Determining and Symbolically
Representing the Function Flow”
The parties agree that the words “function flow” describe
“how functions are associated and interconnected with other
functions.”

In their briefs, the parties disputed whether the

term “Symbolically Representing” is necessarily limited to
“graphical” diagrams such as Binary Decision Diagrams (“BDD”), or
whether it can include other forms of symbolic representation.
At the claim construction hearing, I proposed the construction
“identifying how functions are associated and interconnected with
other functions and representing those associations and
connections through symbols.”

The parties have represented that

they both accept to this construction.
B.

The ‘609 Patent
1. “Optimized”
The parties agree that the ‘609 Patent does not use the term

“Optimized” as it is otherwise generally understood within the
art.

Within the art of software development, “Optimized”

traditionally means that the program is streamlined and made more
efficient.

The ‘609 Patent’s use of the term “Optimized” is not

consistent with this definition.

For instance, the phrase

“processing the executable code to generate an optimized,
exhaustive control flow model,” (‘609 Patent at 15:4-5), implies
that the optimization process ultimately results in a larger,
more complete file rather than a smaller or faster file.
-29-

Appthority argues that the term “Optimized” means “iteratively
refined by repeat analysis of data flow and control flow until
the model is complete and as effective as possible.”

Veracode

argues that “Optimized” means “refined.”
Veracode’s proposed construction is insufficient. Replacing
“Optimized” with “refined” adds no clarity for the jury and
resolves no dispute.
another.

It would substitute one ambiguous term for

In fact, it would impermissibly substitute a more

general term for a more specific one.

“Refined” simply means

“improved” or “made better” without necessarily implying any
particular form of improvement.

“Optimized” implies that

something is transformed into its “best” form.

Thus, “Optimized”

- meaning “made best” - is actually a subset of “refined” meaning “made better.”

The word “refined” would conform to the

Patent’s use of the term “Optimized,” (see, e.g., ‘609 Patent at
6:61-63 (“[A]n optimized (refined) model is produced”)), but it
would add definitional value to the construction of the term
“optimized.”

See Netword, LLC v. Centraal Corp., 242 F.3d 1347,

1352 (Fed. Cir. 2001) (“The role [of claim construction] is
neither to limit nor to broaden the claims but to define, as a
matter of law, the invention that has been patented.”).

Rather,

through reference to other claim language, the specification, and
the prosecution history, a person of ordinary skill in the art
would be able to glean the intended meaning of “optimized.”

-30-

The disputes center around two aspects of Appthority’s
proposed construction: (a) whether the process of optimization in
the ‘609 Patent is necessarily iterative, and (b) how to
characterize the resulting optimized models.
a. Iteration
The specification and prosecution history of the ‘609 Patent
make clear that iteration is an inherent aspect of the
optimization process.

The written description describes how the

invention creates “an optimized (refined) model.”
at 6:63.)

(‘609 Patent

It states that

a first, fitting . . . model is approximated . . . and
then iteratively improved to form a refined . . . model
representing all necessary states and branches within
the code. This double loop occurs, in sequence,
throughout the program, iterating . . . until an
optimized (refined) model is produced.
(Id. at 6:56-63.)

Although this language appears in the

specification and cannot, by itself, operate to limit the claim
language, the patent prosecution history confirms that this
iteration process is inherent in the claims and is not simply
limited to a preferred embodiment.
In the prosecution history of the parent to the ‘609 Patent,
the inventor distinguished prior art (the ‘924 Patent) stating
that independent Claim 1 of the ‘609 Patent, describes a method
whereby “[a] fitting data flow model is identified . . . which is
then optimized . . . to form a refined data flow model;
propagated as a function of the respective defined data flow
-31-

until substantially all data variables are modeled.”

U.S. Patent

App. Serial No. 10/314,005, Amendment (Sept 29, 2005) at 12-13.
The prosecution history uses practically identical language to
describe the propagation of the control flow model.

See id.

Veracode argues that this language describes the optimization
process without reference to iteration, but that appears to
misunderstand the language.

Although the quoted language does

not use the words “iteration” or “iterate,” and is not entirely
clear, it seems to describe an iterative process.

The data flow

model is “propagated as a function of the . . . data flow until .
. . all . . . variables are modeled.”

Id. (emphasis added).

The

word “until” implies that the propagation process does not merely
occur once, but either repeats or continues.

The fact that this

process creates a data flow model using a function of the data
flow itself more than once suggests that the process is iterative
or recursive, recursion being a specific form (and therefore a
subset) of iteration.

Nothing in the independent claim language

using the term “Optimized” implies that the process must
specifically be recursive, but Dependent Claims 2 and 4
specifically use the term “recursion.”

Thus, under the doctrine

of claim differentiation, the independent claims must have the
broader reach of iteration as compared with the dependent claims,
which specify a particular form of iteration:

recursion.

b. Characterization of the Optimized Models

-32-

Appthority’s proposed phrase, “until the model is complete
and as effective as possible” is not tethered to any use of the
term “Optimized” anywhere in the Patent.
never appears in the patent at all.

The word “effective”

The Claims use the word

“complete” only to describe the intermediate representation, (see
‘609 Patent at 15:6-9, 16:31-34), but not to directly describe
the optimized model itself.
Rather, the ‘609 Patent characterizes the optimized models
in the specification where it says that the “model represent[s]
all necessary states and branches within the code” and then
states that the “double loop occurs . . . until [the] optimized
(refined) model is produced.”

The prosecution history also

characterizes the optimized models, stating that Claim 1 recites
“a fitting data flow model . . . which is then optimized . . .
until substantially all data variables are modeled.”

U.S. Patent

App. Serial No. 10/314,005, Amendment (Sept 29, 2005) at 12-13.
It characterizes the optimized control branch model using the
same language as in the data flow model.

Id.

Because the

language in the specification may describe only one particular
embodiment, while the prosecution history characterizes the claim
language itself, I find that the appropriate characterization of
the optimized model is that it models “substantially all data
variables or control branches.”

-33-

I construe “Optimized” to mean “refined by iteration until
substantially all data variables or control branches are
modeled.”
2. “Exhaustive”
Appthority argues that “Exhaustive” means “testing all
program possibilities, or considering all program elements, from
entry to exit.”

Veracode argues that the meaning of the term

“Exhaustive” is clear and that it requires no construction.

I

agree with Veracode that the term “Exhaustive” does not require
construction.
The term “Exhaustive” appears in the claims only and does
not appear in the specification.

Unlike its approach to the term

“Optimized,” the Patent uses “Exhaustive” according to its plain,
ordinary meaning.

The Patent neither uses the word contrary to

its plain meaning, nor is it such a technical or ambiguous word
that the jury will have trouble understanding it.

There is,

therefore, no reason to resort to the complicated definition
Appthority proposes.

See Hoover Grp., Inc. v. Custom Metalcraft,

Inc., 66 F.3d 299, 304 (Fed. Cir. 1995) (applying the ordinary
meaning of a disputed term where “nothing in the specification,
prosecution history, or prior art to suggest other than the
ordinary meaning”).
Appthority argues that the focus and overall thrust of the
Patent language, which emphasizes completeness, counsels in favor

-34-

of construing the term, and cites to the Miriam-Webster Online
Dictionary to support its proposed language, which does not
appear anywhere in the language of the Patent itself or the
Patent’s prosecution history.
construction.

This is not a permissible form of

See Allen Eng. Corp. v. Bartell Indus., Inc., 299

F.3d 1336, 1345 (Fed. Cir. 2002) (“It is well settled that “there
is no legally recognizable or protected essential element, gist
or heart of the invention in a combination patent.

Rather, the

invention is defined by the claims.” (internal citations,
quotations, and alterations omitted)).

A party may not derive

its construction from the overall gist or thrust of the patent,
but must ground its construction in the language of the patent
itself.
I decline to construe the term “Exhaustive.”
3. “Data Flow Signatures”
The parties agree that “Data Flow” means the “process
whereby variables or data storage elements are read from and/or
written to memory.”

The parties also agree that in the context

of the software development art and the ‘609 Patent, the term
“Signatures” is synonymous with “patterns.”

Thus, Veracode

argues that “Data Flow Signatures” means a “pattern of process
whereby variables or data storage elements are read from and/or
written to memory.”

However, Appthority argues that the term

“Signatures” has no coherent meaning when appended to the term

-35-

“Data Flow” and therefore that the full term, “Data Flow
Signatures,” is insolubly ambiguous and indefinite.

See Datamize

LLC v. Plumtree Software, Inc., 417 F.3d 1342, 1346 (Fed. Cir.
2005).

The parties have each submitted expert declarations in

support of their respective positions.
The first problem with Appthority’s argument that the phrase
“Data Flow Signatures” is inherently nonsensical is that the
phrase appears in various articles in the literature.

For

instance, an article entitled “Argus: Low-Cost, Comprehensive
Error Detection in Simple Cores,” published by professors at
Duke, describes a method of checking for errors in a program by
referring to “dataflow signatures.”

A. Meixner, Argus: Low-Cost,

Comprehensive Error Detection in Simple Cases, Appearing in 40th
Annual International Symposium on Microarchitecture (Dec. 2007)
at 3-4.

Similarly, an article in IEEE Security and Privacy

entitled “Toward Application-Aware Security and Reliability”
discusses a “dataflow signature checking” technique which
“encod[es] the instructions that write to the critical object as
a signature and then check[s] the signature at runtime.”

R. K.

Iyer et al., Toward Application-Aware Security and Reliability,
IEEE Security & Privacy (Jan./Feb. 2007) 57, at 59-60.

In other

words, when the program runs, it checks a previously recorded
“signature” of the dataflow.

This use is consistent with the

‘609 Patent’s use of the term “Data Flow Signatures.”

-36-

Although

such extrinsic evidence is not dispositive of a term’s
definiteness, it demonstrates that Appthority’s primary
contention - that the term simply does not make sense in the art
- does not withstand scrutiny.

The intrinsic evidence also

indicates that the term is definite.
In the context of the ‘609 Patent, “Signatures” refer to
patterns of code that the invention can use to identify a stock
function within the code being analyzed.

The Patent incorporates

an article by reference which explains that “patterns were
previously known as signatures in the . . . literature.”

(See

‘609 Patent at 12:2-6 (citing M. Van Emmerik, “Signatures for
Library Functions in Executable Files Using Patterns,”
Proceedings of the 1998 Australian Software Engineering
Conference, Adelaide, 9-13 November, 1998, IEEE-CS Press, pp. 90
n. 1).)

Claim 1 of the ‘609 Patent states that the invention

“process[es] the executable software code to generate an
optimized, exhaustive data flow model . . . .”

(‘609 Patent at

14:66-67.)
Claim 11, which depends on Claim 1 describes the invention’s
method of generating the exhaustive data flow model, stating that
it “generat[es] data flow signatures for the executable software
code; and compar[es] the generated data flow signatures to one or
more predefined data flow signatures, each representing a data
flow model.”

(Id. at 15:51-16:3.)

-37-

In simpler terms, part of the

way in which the ‘609 Patent generates the exhaustive data flow
model is by seeking out patterns in the way pieces of the
analyzed code read and write data to memory that correspond to
known patterns in order to identify known models for those pieces
of code.
Appthority’s expert, Dr. Paul Clark, suggests that “Data
Flow Signatures” is indefinite because software fingerprinting
techniques, such as cyclic redundancy codes (“CRC”s), must apply
to particular pieces of data, not “data flow.”

He also contends

that it is not possible to compare patterns of such specific data
against known libraries because they will be located in ranges of
code specific to that piece of software and are therefore not
amenable to comparison with standard models.
However, Dr. Clark’s Declaration misunderstands the purposes
of data flow signatures in the ‘609 Patent.

The Patent does not

mention CRCs or the other signature techniques Dr. Clark
references.

Furthermore, as Dr. Aviel Rubin, Veracode’s expert,

explains, the CRCs and the signature techniques Dr. Clark
discusses are irrelevant to the ‘609 Patent because they test
data integrity - ensuring that the particular data in one place
is the same as data in another location after the program
transmits that data.

They do not, as the Patent calls for,

identify a pattern of reading and writing data that might be
associated with a known model.

Because the CRC and other data-

-38-

integrity techniques Dr. Clark discusses are not relevant to the
‘609 Patent, the fact that they cannot apply to “data flow” does
not render the claim indefinite.
Dr. Clark also contends that the concept of “Data Flow
Signatures” is nonsensical because the data produced by a program
being analyzed are not drawn from general purpose external
libraries, but are produced by the running of the application
itself.

He states that “an example of such data would be the

input from the other code in the system being debugged” and that
he “understand[s] this to be referred to as ‘data flow’ within
the context of the patent.”

Again, this misunderstands the

meaning of “Data Flow” in the context of the ‘609 Patent.
First and foremost, this argument is inconsistent with Dr.
Clark’s other argument.

In paragraph 11 of his Declaration,

discussed above, Dr. Clark assumes, correctly, that “Data Flow”
refers to the process and flow of reading and writing data.
However, in paragraph 10, he assumes, incorrectly, that “data
flow” refers to the discrete data actually written by the
program.

Dr. Clark’s analysis and “understanding” in paragraph

10 incorrectly and inapplicably refers to the data itself rather
than the data flow despite his apparently correct understanding
of data flow in paragraph 11.
Dr. Clark’s argument in paragraph 10 is unpersuasive for the
additional reason that the “pattern” that the ‘609 Patent seeks

-39-

to uncover is not in the substantive content actually written and
read, but rather in the pattern of reading and writing - like the
pattern of points where water flows into or out of a river, not
the specific water flowing through it (data), or the path of the
bends in the river (control flow).

He may be correct that it

would be nonsensical to attempt to identify a known model of a
particular aspect of a program by looking at the data written by
the analyzed program as it runs.

This data is unique to the

application and might not help to identify a particular model.
However, the term “data flow” does not refer to the data itself,
but to the pattern of writing to and reading from memory.

It

would be difficult to identify a river by looking solely at the
molecules of water that flow through it, but much easier to
identify it by looking at pattern of twists and turns (analogous
to the control flow the Patent describes), or, more specific to
this term:

the pattern of the tributaries flowing into the river

and the pattern of distributaries flowing out (analogous to the
data flow the Patent describes.
The parties agree that the meaning of the term “Data Flow”
is the “process whereby variables or data storage elements are
read from and/or written to memory.”

I find that, in the context

of the ‘609 Patent, the term “Data Flow Signatures” refers to the
concept of patterns in this process, which, when compared to
pattern libraries of similar data flows might help identify known

-40-

models for those programs.

The term is therefore amenable to

construction and neither insolubly ambiguous nor indeterminate.
I construe “Data Flow Signatures” to mean the “pattern of
process whereby variables or data storage elements are read from
and/or written to memory.”
4. “Flaws”
Appthority argues that the term “Flaws” in the ‘609 Patent
means “software errors i.e., ‘unintended programming mistakes
inconsistent with the program’s intended design’” or should
otherwise have the same construction as “Program Flaws” from the
‘924 Patent.

Veracode argues that a jury can readily understand

the term “Flaws” and that it therefore requires no construction.
Appthority’s proposed construction is nearly identical to
the one that it suggested - and that I have already rejected for the meaning of the term “Program Errors” in the ‘924 Patent.
(See supra Section III(A)(2).)

It is even less appropriate here

than it was as a proposed construction of “Program Errors.”
term “Flaw” is broader than either “error” or “mistake.”

The

It

allows for subjective deficiencies in quality, both intentional
and unintentional, in addition to the objective inaccuracies
captured by the words “error” and “mistake.”

Thus, in the

context of the patents in suit, a “mistake” is a subset of
“error,” which, in turn, is a subset of “flaw.”

As I have

already rejected Appthority’s attempt to limit the term “error”

-41-

to mean “mistake,” I also reject its attempt to limit the broader
term “Flaw” in the same way.
As with the term “Program Errors,” the crux of the dispute
between the parties is whether a “Flaw” must be unintentional and
whether it must be contrary to the program’s intended design.

As

in its proposed construction of “Program Errors,” discussed
above, Appthority here relies on the MS Computer Dictionary
definition of “error” despite a number of apparent deficiencies
in such an argument, including that (1) Appthority does not cite
to a dictionary definition of the term here under construction,
“Flaw,” but to the definition of an entirely different word:
“error;” (2) the word “error” does not appear anywhere in the
‘609 Patent; and (3) even if the word “error” were somehow
relevant to construction of the ‘609 Patent, the cited definition
says nothing about the two limitations Appthority seeks to
impose:

whether an error must be unintentional or whether it

must be contrary to the purpose of the program.
Nothing about the plain meaning of the term “Flaw” implies
that a flaw cannot be intentional or that a flaw must be contrary
to the purposes of a program.

In fact, the language in the

abstract, the summary, and the specification indicate that the
‘609 Patent specifically contemplates the possibility of
intentional flaws.

The Patent Abstract states that “[t]he nano-

code decompiler may be used to determine if flaws, security

-42-

vulnerabilities, or general quality issues exist in the code.”
(‘609 Patent, Abstract.)

The Patent summary states that the

“decompiler may produce . . . a report showing the flaws,
vulnerabilities, and/or poor programming practices in the
original executable code . . . [including] flaws and pointers to
badly constructed data structures, unchecked buffers, malicious
embedded code or ‘trap doors,’ and the like.”

(Id. at 3:1-10.)

Finally, the specification states that the “executable code can
thus be scanned or analyzed for flaws or conditions, especially
including security holes, bugger structure flaws exploitable via
‘buffer overflow’ attack, and other known and unknown risk
factors.”

(Id. at 11:1-5.)

Thus, the ‘609 Patent specifically

contemplates security vulnerabilities including the buffer
overflow attack that Dr. Rubin discusses by name and which he
describes in his first Declaration as potentially intentional.
The ‘609 Patent specifically contemplates security
vulnerabilities, malicious embedded code, and other risk factors
in the flaws it searches for, any of which may be part of the
purpose of a given program and any of which may be intentional.
I will not limit the term “Flaws” to exclude elements that the
language of the Patent specifically includes.
Appthority’s argues that I should limit the meaning of
“Flaw” because the both the patent abstract and the summary list
“flaws” as one of a variety of examples of programming problems,

-43-

including security vulnerabilities and general quality issues.
Appthority reasons that under doctrines of Patent construction,
“Flaw” must have a different meaning from the other examples in
the list, such as “security vulnerabilities.”

See Comark, 156

F.3d at 1187 (when different words are used in separate claims,
they are presumed to have different meanings).
fails for a number of reasons.

This argument

First, the fact that the terms

should not be construed as synonymous does not necessarily
require that the terms be mutually exclusive.

Second, Appthority

offers no justification why any difference in meaning between
“Flaw” and “security vulnerabilities” would require that flaws be
unintentional or contrary to the purpose of a program.

Finally,

Appthority’s argument ignores the plain language of the patent
specification which uses the phrase “security holes” as an
example of a “flaw.”

(See ‘609 Patent at 11:2-3.)

The

specification states that patented invention scans executable
code for “flaws or conditions including security holes, buffer
structure flaws exploitable via ‘buffer overflow’ attack, and
other known and unknown risk factors.”
added).)

(Id. at 11:1-5 (emphasis

The specification specifically includes potentially

intentional security holes and buffer structure flaws within the
meaning of the term “Flaws.”
Appthority suggests that security holes may be one of the
“Conditions” rather than one of the “Flaws” mentioned, but this

-44-

also does not comport with the plain language.

The phrase states

that “flaws or conditions include[] security holes . . . and
other known and unknown risk factors.” This sentence utilizes
parallel structure:

A or B including X and Y.

Parallel

structure suggests that the first half of the phrase before
“including” connects with the first half of the phrase after
“including” and the same is true for the second half of each
phrase.

Thus, parallel structure suggests that the security

holes and buffer structure flaws are “Flaws” and the “Conditions”
are “other known and unknown risk factors.”

In fact, the patent

specifically refers to buffer overflow attack - undeniably a
security hole - as a buffer structure flaw.

The mental

gymnastics that Appthority suggests in order to distinguish
between “Flaws” and security vulnerabilities does not comport
with the plain claim language.

The limitations Appthority seeks

to impose on the term “Flaw” are not appropriate.
Unlike the term “Program Errors,” as discussed above, see
Section III(A)(2), the term “Flaw” does not require construction
to resolve the parties’ dispute.

I have rejected the limitations

Appthority seeks to impose on the term “Flaw,” and the term does
not have the same unintuitive or ambiguous meaning in the context
of the ‘609 Patent that the term “Program Error” had in the
context of the ‘924 Patent.

-45-

The meaning of the term “Flaw” is clear from the plain
meaning of the word and its use in the Patent.

I therefore

decline to construe it.
IV. CONCLUSION
For the reasons set out at length above, I construe the
terms of the various claims as set forth in this Memorandum, and
as summarized in the Appendix, see infra Section V.

/s/ Douglas P. Woodlock
DOUGLAS P. WOODLOCK
UNITED STATES DISTRICT JUDGE

-46-

V.
A.

APPENDIX: CLAIM CONSTRUCTION SUMMARY

Patent No. 5,854,924

1. Phrase(s) in Patent

“Debugging”

Plaintiffs’ Construction

[Preamble is not limiting]

Defendants’ Construction

“Allowing Software developers
to detect, locate, or correct
logical or syntactical errors
in or malfunctions of a
program.”

Court’s Construction

[Preamble is not limiting]

2. Phrase(s) in Patent

“Program Errors”

Plaintiffs’ Construction

[Does not require
construction]

Defendants’ Construction

“Unintended programming
mistakes inconsistent with the
program’s intended design”

Court’s Construction

“the result of an invalid or
impossible maneuver”

3. Phrase(s) in Patent

“Intermediate File”

Plaintiffs’ Construction

“A representation of the
binary file that is not source
code”

Defendants’ Construction

“Machine independent
representation of the binary
file”

Court’s Construction

“a representation of the
binary file that is neither in
binary code nor source code”

-47-

4. Phrase(s) in Patent

“Decompiler”

Plaintiffs’ Construction

“Software that translates the
binary program file into an
intermediate, machine
independent program file”

Defendants’ Construction

“Tool for converting the
binary code to machine
independent, high-level source
code”

Court’s Construction

“A tool for translating the
binary program file into an
intermediate, machine
independent program file”

5. Phrase(s) in Patent

“Determining and Symbolically
Representing the Function
Flow”

Plaintiffs’ Construction

“Identifying and describing
how functions are associated
and interconnected with other
functions”

Defendants’ Construction

“Depicting how functions are
associated and interconnected
with other functions via
binary decision diagrams
(BDDs) or other graphical
diagrams”

Court’s Construction

“identifying how functions are
associated and interconnected
with other functions and
representing those
associations and connections
through symbols”

-48-

B. Patent No. 7,752,609
1. Phrase(s) in Patent

“Optimized”

Plaintiffs’ Construction

“Refined”

Defendants’ Construction

“Iteratively refined by repeat
analysis of data flow and
control flow until the model
is complete and as effective
as possible”

Court’s Construction

“refined by iteration until
substantially all data
variables or control branches
are modeled”

2. Phrase(s) in Patent

“Exhaustive”

Plaintiffs’ Construction

[Does not require
construction]

Defendants’ Construction

“Testing all program
possibilities, or considering
all program elements, from
entry to exit”

Court’s Construction

[Does not require
construction]

3. Phrase(s) in Patent

“Data Flow Signatures”

Plaintiffs’ Construction

“Pattern of processes whereby
variables or data storage
elements are read from and/or
written to memory”

Defendants’ Construction

[Indefinite]

Court’s Construction

“Pattern of processes whereby
variables or data storage
elements are read from and/or
written to memory”

-49-

4. Phrase(s) in Patent

“Flaws”

Plaintiffs’ Construction

[Does not require
construction]

Defendants’ Construction

“Software errors, i.e.,
unintended programming
mistakes inconsistent with the
program’s intended design”

Court’s Construction

[Does not require
construction]

-50-