Blue Spike, LLC v. Toshiba America, Inc. et al
Filing
46
MEMORANDUM AND OPINION, and ORDER. Signed by Magistrate Judge John D. Love on 6/28/2017. (gsg)
IN THE UNITED STATES DISTRICT COURT
FOR THE EASTERN DISTRICT OF TEXAS
TYLER DIVISION
BLUE SPIKE, LLC,
Plaintiff,
v.
TOSHIBA AMERICA, INC. et al.,
Defendants.
§
§
§
§
§
§
§
§
§
§
§
CIVIL ACTION NO. 6:16-CV-00430
JDL
MEMORANDUM OPINION AND ORDER
On May 13, 2016, Plaintiff filed this action for patent infringement. Plaintiff alleges
that Defendants Toshiba America, Inc., Toshiba Corporation, and Toshiba America Information
Systems, Inc. (collectively, “Toshiba”) infringe claims of U.S. Patent No. 5,745,569 (“the ’569
Patent”) and U.S. Patent No. 8,930,719 (“the ’719 Patent”) (collectively, “Asserted Patents”).
(See Doc. No. 6 (Amended Complaint).)
This claim construction opinion construes disputed claim terms in the Asserted Patents.
Blue Spike has filed an Opening Claim Construction Brief (Doc. No. 29), Defendants have filed
a Response (Doc. No. 32), and Blue Spike has filed a Reply (Doc. No. 33). The parties
additionally submitted a Joint Claim Construction Chart pursuant to P.R. 4-5(d). (Doc. No. 34.)
On April 21, 2017, the Court held a claim construction hearing. Upon consideration of the
parties’ arguments and for the reasons stated herein, the Court adopts the constructions set forth
below.
1
OVERVIEW OF THE PATENTS
The Asserted Patents generally relate to improving computer security through digital
watermarking and relocating all or portions of software in memory.
Abstract, 2:21–22; ’719 Patent, at 1:21–23.
See ’569 Patent, at
The ’569 Patent, entitled “METHOD FOR
STEGA-CIPHER PROTECTION OF COMPUTER CODE,” issued on April 28, 1998 from an
application filed Jan. 17, 1996. The ’719 Patent, entitled “DATA PROTECTION METHOD
AND DEVICE,” issued on Jan. 6, 2015 and claims priority to series of parent applications, the
earliest filed March 24, 1998. The ’719 Patent does not claim priority to the ’569 Patent.
However, substantially all of the specification of the ’569 Patent appears in the specification of
the ’719 Patent.1 Blue Spike asserts Claims 16–20 of the ’569 Patent and Claims 10–12 and 22
of the ’719 Patent. (See Doc. No. 36.) Claim 16 of the ’569 Patent is an independent claim and
Claims 17–20 depend from Claim 16. Claim 16 of the ’569 Patent recites:
16. A method for copy protecting a software application executed by a computer
system, the software application including a plurality of executable code
resources loaded in a memory of the computer system, said method comprising
the steps of:
determining an address within the memory of the computer system
associated with each of the plurality of executable code resources;
and
intermittently relocating each of the plurality of executable code resources
to a different address within the memory of the computer during
execution of the software application.
’569 Patent, at 10:9–19.
Claims 10 and 22 of the ’719 Patent are independent claims and Claims 11 and 12
depend from Claim 10. Claim 10 recites:
10. A system for executing application software code, comprising:
a memory designed to store data in non transitory form, and storing
executable code resources;
1
For common portions of the specification, the Court cites to the ’569 Patent.
2
wherein said executable code resources comprise a memory scheduler and
other executable code resources;
wherein said memory scheduler is designed to shuffle said other
executable code resources in said memory; and
wherein said memory scheduler is designed to modify a stack frame in
said memory.
’719 Patent, at 16:60–17:2.
Claim 22 of the ’719 Patent recites:
22. A system comprising:
a processor designed to process instructions;
a memory designed to store data in non transitory form;
wherein said processor is coupled to said memory;
wherein said system is configured to load an executable program
comprising at least two code resources into said memory and to
randomize the location of at least one of the at least two code
resources in the said memory, using said processor; and
wherein one of the at least two code resources is designed to modify a
stack frame in said memory.
’719 Patent, at 17:52–62.
The Court has previously construed terms of the ’569 Patent claims in Blue Spike v.
Huawei, No. 6:13-cv-679-RWS, Doc. No. 194 (E.D. Tex. May 16, 2016) (“Huawei Order”).
LEGAL STANDARD
“It is a ‘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 v. AWH Corp., 415 F.3d 1303,
1312 (Fed. Cir. 2005) (quoting Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381
F.3d 1111, 1115 (Fed. Cir. 2004)). The Court examines a patent’s intrinsic evidence to define
the patented invention’s scope.
Id. at 1313–14; Bell Atl. Network Servs., Inc. v. Covad
Commc’ns Group, Inc., 262 F.3d 1258, 1267 (Fed. Cir. 2001). Intrinsic evidence includes
the claims, the rest of the specification, and the prosecution history. Phillips, 415 F.3d at
1312–13; Bell Atl. Network Servs., 262 F.3d at 1267. The Court gives claim terms their
ordinary and customary meaning as understood by one of ordinary skill in the art at the time of
3
the invention. Phillips, 415 F.3d at 1312–13; Alloc, Inc. v. Int’l Trade Comm’n, 342 F.3d 1361,
1368 (Fed. Cir. 2003). Claim language guides the Court’s construction of claim terms.
Phillips, 415 F.3d at 1314. “[T]he context in which a term is used in the asserted claim can be
highly instructive.”
Id.
Other claims, asserted and unasserted, can provide additional
instruction because “terms are normally used consistently throughout the patent.”
Id.
Differences among claims, such as additional limitations in dependent claims, can provide
further guidance. Id.
“[C]laims ‘must be read in view of the specification, of which they are a part.’”
Id. (quoting Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995)).
“[T]he specification ‘is always highly relevant to the claim construction analysis. Usually, it is
dispositive; it is the single best guide to the meaning of a disputed term.’”
Id. (quoting
Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)); Teleflex. Inc. v.
Ficosa N. Am. Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002). In the specification, a patentee may
define his own terms, give a claim term a different meaning than it would otherwise
possess, or disclaim or disavow some claim scope. Phillips, 415 F.3d at 1316. Although the
Court generally presumes terms possess their ordinary meaning, this presumption can be
overcome by statements of clear disclaimer.
See SciMed Life Sys., Inc. v. Advanced
Cardiovascular Sys., Inc., 242 F.3d 1337, 1343–44 (Fed. Cir. 2001). This presumption does
not arise when the patentee acts as his own lexicographer.
See Irdeto Access, Inc. v.
EchoStar Satellite Corp., 383 F.3d 1295, 1301 (Fed. Cir. 2004).
The specification may also resolve ambiguous claim terms “where the ordinary and
accustomed meaning of the words used in the claims lack sufficient clarity to permit the scope of
the claim to be ascertained from the words alone.” Teleflex, Inc., 299 F.3d at 1325. For
4
example, “[a] claim interpretation that excludes a preferred embodiment from the scope of the
claim ‘is rarely, if ever, correct.” Globetrotter Software, Inc. v. Elan Computer Group Inc., 362
F.3d 1367, 1381 (Fed. Cir. 2004) (quoting Vitronics Corp., 90 F.3d at 1583). But, “[a]lthough
the specification may aid the court in interpreting the meaning of disputed language in the
claims, particular embodiments and examples appearing in the specification will not generally be
read into the claims.” Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed. Cir.
1988); see also Phillips, 415 F.3d at 1323.
The prosecution history is another tool to supply the proper context for claim
construction because a patentee may define a term during prosecution of the patent. Home
Diagnostics Inc. v. LifeScan, Inc., 381 F.3d 1352, 1356 (Fed. Cir. 2004) (“As in the case of the
specification, a patent applicant may define a term in prosecuting a patent.”).
The well-
established doctrine of prosecution disclaimer “preclud[es] patentees from recapturing through
claim interpretation specific meanings disclaimed during prosecution.” Omega Eng’g Inc. v.
Raytek Corp., 334 F.3d 1314, 1323 (Fed. Cir. 2003). The prosecution history must show that the
patentee clearly and unambiguously disclaimed or disavowed the proposed interpretation during
prosecution to obtain claim allowance. Middleton Inc. v. 3M Co., 311 F.3d 1384, 1388 (Fed. Cir.
2002); see also Springs Window Fashions LP v. Novo Indus., L.P., 323 F.3d 989, 994 (Fed. Cir.
2003) (“The disclaimer . . . must be effected with ‘reasonable clarity and deliberateness.’”)
(citations omitted)). “Indeed, by distinguishing the claimed invention over the prior art, an
applicant is indicating what the claims do not cover.” Spectrum Int’l v. Sterilite Corp., 164 F.3d
1372, 1378–79 (Fed. Cir. 1988) (quotation omitted).
“As a basic principle of claim
interpretation, prosecution disclaimer promotes the public notice function of the intrinsic
evidence and protects the public’s reliance on definitive statements made during prosecution.”
5
Omega Eng’g, Inc., 334 F.3d at 1324. Statements in the prosecution history that are subject to
multiple reasonable interpretations do not constitute a clear and unmistakable departure from the
ordinary meaning of a claim term. Golight, Inc. v. Wal-Mart Stores, Inc., 355 F.3d 1327, 1332
(Fed. Cir. 2004).
Although “less significant than the intrinsic record in determining the legally operative
meaning of claim language,” the Court may rely on extrinsic evidence to “shed useful light on
the relevant art.” Phillips, 415 F.3d at 1317 (quotation omitted). Technical dictionaries and
treatises may help the Court understand the underlying technology and the manner in which one
skilled in the art might use claim terms, but such sources may also provide overly broad
definitions or may not be indicative of how terms are used in the patent. Id. at 1318. Similarly,
expert testimony may aid the Court in determining the particular meaning of a term in the
pertinent field, but “conclusory, unsupported assertions by experts as to the definition of a claim
term are not useful.” Id. Generally, extrinsic evidence is “less reliable than the patent and its
prosecution history in determining how to read claim terms.” Id.
In patent construction, “subsidiary fact finding is sometimes necessary” and the court
“may have to make ‘credibility judgments’ about witnesses.” Teva v. Sandoz, 135 S.Ct. 831, 838
(2015). In some cases, “the district court will need to look beyond the patent’s intrinsic evidence
and to consult extrinsic evidence in order to understand, for example, the background science or
the meaning of a term in the relevant art during the relevant time period.” Id. at 841. “If a
district court resolves a dispute between experts and makes a factual finding that, in general, a
certain term of art had a particular meaning to a person of ordinary skill in the art at the time of
the invention, the district court must then conduct a legal analysis: whether a skilled artisan
would ascribe that same meaning to that term in the context of the specific patent claim under
6
review.” Id. (emphasis in original). When the court makes subsidiary factual findings about the
extrinsic evidence in consideration of the “evidentiary underpinnings” of claim construction,
those findings are reviewed for clear error on appeal. Id.
A patent claim may be expressed using functional language. See 35 U.S.C. § 112, ¶ 6;
Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1347–49 & n.3 (Fed. Cir. 2015) (en banc in
relevant portion). Section 112, paragraph 6,2 provides that a structure may be claimed as a
“means . . . for performing a specified function” and that an act may be claimed as a “step for
performing a specified function.” Masco Corp. v. United States, 303 F.3d 1316, 1326 (Fed. Cir.
2002).
But section 112, paragraph 6 does not apply to all functional claim language. There is a
rebuttable presumption that section 112, paragraph 6 applies when the claim language includes
“means” or “step for” terms, and that it does not apply in the absence of those terms. Masco
Corp., 303 F.3d at 1326; Williamson, 792 F.3d at 1348. The presumption stands or falls
according to whether one of ordinary skill in the art would understand the claim with the
functional language, in the context of the entire specification, to denote sufficiently definite
structure or acts for performing the function. See Media Rights Techs., Inc. v. Capital One Fin.
Corp., 800 F.3d 1366, 1372 (Fed. Cir. 2015) (§ 112, ¶ 6 does not apply when “the claim
language, read in light of the specification, recites sufficiently definite structure” (quotation
marks omitted) (citing Williamson, 792 F.3d at 1349; Robert Bosch, LLC v. Snap-On Inc., 769
F.3d 1094, 1099 (Fed. Cir. 2014))); Williamson, 792 F.3d at 1349 (§ 112, ¶ 6 does not apply
when “the words of the claim are understood by persons of ordinary skill in the art to have
sufficiently definite meaning as the name for structure”); Masco Corp., 303 F.3d at 1326 (§ 112,
2
The America Invents Act renumbered section 112, paragraph 6 to section 112(f). However, because each of the
patents at issue in this case was originally filed before September 16, 2012, the Court will refer to this code section
by its previous numbering, section 112, paragraph 6.
7
¶ 6 does not apply when the claim includes an “act” corresponding to “how the function is
performed”); Personalized Media Commc’ns, L.L.C. v. Int’l Trade Comm’n, 161 F.3d 696, 704
(Fed. Cir. 1998) (§ 112, ¶ 6 does not apply when the claim includes “sufficient structure,
material, or acts within the claim itself to perform entirely the recited function . . . even if the
claim uses the term ‘means.’” (quotation marks and citation omitted)).
DISCUSSION
I.
AGREED CLAIM TERM CONSTRUCTIONS
In its reply brief, Blue Spike agreed to Toshiba’s proposed construction of the terms “a
software application/application” as “a software program run by an operating system.” (Doc.
No. 33, at 2–3.) The term “a software application” appears in Claims 16 and 17 of the ’569
Patent and the term “application” appears in Claim 10 of the ’719 Patent. In light of the parties’
agreement and a review of the asserted claims, specifications, and prosecution history, the Court
adopts Defendant’s proposed construction.
II.
DISPUTED CLAIM TERMS
a. program
Claim Term
Plaintiffs’ Proposal
Defendants’ Proposal
“program”
Plain and ordinary
“a set of instructions run by an
operating system”
(’719 patent, Claim
22)
Alternate construction:
“A software program run by an
operating system”
The sole dispute between the parties with respect to the term “program” (occurring in the
context of Claim 22 of the ’719 Patent as “an executable program . . .”) is whether it
8
encompasses an operating system. Blue Spike argues, without citation, that the ’719 Patent uses
“program” in its plain and ordinary sense. (Doc. No. 29, at 17.) Blue Spike objects to Toshiba’s
construction as “an attempt to distinguish the operating system as something separate from a
program.” (Id.) According to Blue Spike, an operating system is a program “developed by
software developers just as a program is developed.” (Id.)
Toshiba argues that the claims refer to a system configured to “load an executable
program” into memory. See ’719 Patent, Claim 22. Toshiba argues that in the Huawei Order,
the Court found that loading preceded execution. (Doc. No. 32, at 8 (citing Huawei Order, at 7).)
Toshiba contends that it is “without question” that the operating system loads the executable
program. (Id.) Therefore, Toshiba argues, the operating system must be part of the system of
Claim 22 and not a loadable program. (Id.) Toshiba further contends that the specification
consistently draws a distinction between an executable program and an operating system. (Id.
(citing ’569 Patent, at 7:30-34 (“[o]nce the code resources of a program are loaded into memory,
they typically remain in a fixed position, unless the computer operating system finds it necessary
to rearrange certain portions of memory during ‘system time,’ when the operating system code,
not application code is running.”); 7:38-39 (“in order to allow the operating system to rearrange
memory transparently, underneath a running program.”)).)
Toshiba also argues that the
specification equates “program” and “application” by explaining to an engineer that a “computer
program is variously referred to as an application, from the point of view of a user.” (Id. at 9
(citing ’569 Patent, at 3:44-45).)
Blue Spike replies by noting that in the Huawei Order, the Court drew a distinction
between “applications” and “programs.” (Doc. No. 33, at 3.) In Huawei, the Court found that “it
is more accurate to say that the intrinsic record treats applications as a subset of a computer
9
programs [sic] rather than equating the two.”
Huawei Order, at 10–11.
Blue Spike thus
contends that both an operating system and a software application are types of programs. (Doc.
No. 33, at 3.) Blue Spike further argues, contrary to some of Toshiba’s assertions, that “[a]n
operating system is executed by a computer just as applications are.” (Id. at 4.) Blue Spike
reiterates that a person of ordinary skill in the art would agree that an operating system is a
program. (Id.)
The parties do not dispute that in the abstract, an operating system is a program. The
issue is whether the term “executable program” includes operating systems in the context of the
Asserted Patents. Claim 22 of the ’719 Patent recites, inter alia, “a system . . . wherein said
system is configured to load an executable program comprising at least two code resources . . . .”
Toshiba argues, without support from a person of skill in the art, that in order to practice the
claim, the operating system must already be part of the claimed system such that it can load other
programs. Blue Spike argues, without support from a person of skill in the art, that the claimed
system does not require an operating system and indeed can load and execute an operating
system the same as any other program. Based solely on a review of the claim language and the
parties’ conflicting attorney argument, it is entirely unclear whether the patent applicants
intended to limit the term “executable program” to exclude operating systems.
The specification, on the other hand, does draw a clear distinction between an executable,
or running, program and the operating system. See ’569 Patent, at 7:34–39 (“[t]he MacOS for
example, uses Handles, which are double-indirect pointers to memory locations, in order to
allow the operating system to rearrange memory transparently, underneath a running
program.”) Indeed, the specification equates the term “program” with the term “application,”
stating, “[a]n executable computer program is variously referred to as an application, from the
10
point of view of a user, or executable object code from the point of view of the engineer.” See,
e.g., ’569 Patent, at 3:44–47; see also id. at 1:50–52 (“Computer application programs can be
watermarked . . .”); id. at 2:21–26; id. at 2:27–31 (“In this way, attempts to capture memory to
determine underlying functionality or provide a ‘patch’ to facilitate unauthorized use of the
‘application,’ or computer program, without destroying the functionality and thus usefulness of
a copyrightable computer program can be made difficult.”); id. at 5:40–6:8 (interchanging the
terms “program,” “application,” “application program,” “executable program,” and “executable
application”); (Doc. No. 29, at 12). In turn, as the parties agree, the specification clearly
distinguishes between an “application” and an “operating system.” ’569 Patent, at 7:30–34
(explaining that after code resources are loaded into memory, the computer operating system
may find it necessary to rearrange portions of memory during “‘system time,’ when the operating
system code, not application code, is running.”); ’719 Patent, Claim 1 (claiming a computing
device with an operating system and memory that stores an application software). Based on the
specification’s disclosure, the Court finds that the applicant clearly disclaimed the full scope of
the term “program.” In the context of the Asserted Patents, an “executable program” does not
include an operating system.
Moreover, Claim 22 of the ’719 Patent recites a system configured to “load an executable
program.” The specification never references “loading” in the context of initially loading an
operating system. Rather, “loading” is used with reference to a program or application being
loaded by the operating system. See, e.g., ’569 Patent, at 7:30–34; see also id. at 4:61–67 (“there
are a certain sub-set of executable code resources, that comprise an application and that are
‘essential’ to the proper function of the application. In general, any code resource can be
considered ‘essential’ in that if the program proceeds to a point where it must ‘call’ the code
11
resource and the code resource is not present in memory, or cannot be loaded, then the program
fails.”) This disclosure further indicates that within the context of the Asserted Patents, an
executable program does not include an operating system.
Blue Spike refers to the Huawei Order to argue that this Court previously found software
programs are not equivalent to software applications. See Huawei Order, at 10–11 (“the intrinsic
record treats applications as a subset of [] computer programs rather than equating the two”).
However, the Huawei Order did not construe the term “program,” or specifically address
whether the term “program” in the context of the patent specification includes operating systems.
Further, Huawei’s conclusion was solely based on drawing a distinction between some claim
preambles that refer to “copy protection of computer software” compared to others that refer to
“copy protecting a software application.” Compare ’569 Patent, Claim 1 with id. at Claim 16.
This comparison does not actually address the comparison of “program” to “application,” but
rather refers to “software” versus “application.” Further, while there is a “general presumption
that different terms have different meanings,” the numerous portions of the specification, cited
above, that use the terms “program” and “application” interchangeably overcome this
presumption. See CAE Screenplates, Inc. v. Heinrich Fiedler GmbH & Co. KG, 224 F.3d 1308,
1317 (Fed.Cir.2000); Fargo Elecs., Inc. v. Iris Ltd., Inc., No. 04-1017 JRT/FLN, 2005 WL
3241851, at *14 (D. Minn. Nov. 30, 2005), aff'd, 287 F. App'x 96 (Fed. Cir. 2008); see, e.g.,
’569 Patent, at 3:44–47 (“[a]n executable computer program is variously referred to as an
application. . . .”).
Accordingly, the Court construes the term “a program” as “a set of instructions run by an
operating system.”
12
b. memory scheduler
Claim Term
“memory
scheduler”
Plaintiffs’ Proposal
Plain and ordinary
Defendants’ Proposal
Means-plus-function limitation
(Indefinite)
(’719 patent, Claim
10, 11, 12; ’569
Patent, Claim 17, 18,
19, 20);
Claimed Function: During
execution time (i) shuffle or
randomize other code resources in
memory; (ii) modify a stack frame
in memory; (iii) modify a value
stored by a program counter; (iv)
modify a calling address; (v) copy
itself to a memory location
associated with a calling address;
(vi) maintain a list of addresses;
(vii) shuffle itself randomly in
memory. There must be a
disclosed algorithm for performing
the recited functions; if not, then it
is indefinite.
No corresponding structure is
disclosed; there is no algorithm;
therefore, the term is indefinite.
Alternate construction:
memory scheduler, wherein the
memory scheduler is within the/a
software application
Blue Spike contends, without citation, that a “scheduler” is “[a] computer program
designed to perform functions such as scheduling, initiation, and termination of jobs.” (Doc. No.
29, at 13.) Blue Spike states a “memory scheduler” specifically is “a scheduler of RAM or a
‘memory scheduler.’” (Id.)
Toshiba argues that the terms “memory scheduler code resource” and “memory
scheduler” are means-plus-function limitations for which both Asserted Patents fail to disclose
13
any corresponding structure. (Doc. No. 32, at 16.) Toshiba contends that the term “scheduler” is
a nonce term that functions as a “black box.” (Id.) Toshiba contends the Asserted Patents’ only
description of the “memory scheduler” simply introduces the term as a “‘special” code
resource.” (Id. at 16 (emphasis in original) (citing ’569 Patent, at 8:1–19).) Further, Toshiba
argues that the fact that the applicants introduced the term “memory scheduler” using quotation
marks shows that it is effectively a nonce word without established meaning. (Id.) Toshiba
contends that in the context of software technology, Blue Spike’s definition of “scheduler”
confirms that “memory scheduler” has no “well understood structural meaning in the computer
technology field.” (Id. at 17.) Toshiba notes that Blue Spike has provided no evidence as to how
one skilled in the art would interpret “memory scheduler” to connote structure. (Id.)
On reply, Blue Spike contends that “memory scheduler” is itself sufficiently descriptive;
it is not a non-structural term. (Doc. No. 33, at 4–5 (citing Smartflash LLC v. Apple Inc., 77 F.
Supp. 3d 535, 541 (E.D. Tex. 2014) (noting that the term “processor” is “not a generic
nonstructural term such as ‘means’, ‘element’, and ‘device’ that typically do not connote
sufficient structure”)).) Blue Spike contends that unlike “module” in Williamson, the term
“scheduler” is readily understood in the art: “scheduler n. A computer program designed to
perform functions such as scheduling, initiation, and termination of jobs.” (Id. at 5 (quoting Doc.
No. 33, Ex. 8 (Dictionary of IBM & Computing Terminology) at 80).) Blue Spike argues that
the intrinsic record fully supports its proposed construction of “memory scheduler.” (Id. at 5–6.)
Toshiba’s argument that the term “scheduler” lacks a known meaning in the computer
technology field is belied by the fact that the term is specifically defined in computer
dictionaries.
The Dictionary of IBM & Computing Terminology specifically defines a
“scheduler” as a type of computer program that performs certain functions. (Doc. No. 33, Ex. 8.)
14
This demonstrates that the term “scheduler,” like the term “processor,” has a generally
understood meaning in the art. Toshiba argues that “the performance of functions by a computer
program is nothing more than a generic phrase,” thus rendering this dictionary definition
meaningless. (Doc. No. 32, at 18.) Toshiba, however, does not rely on an expert declaration or
any other recitation of a person of skill in the art to support this argument. Nor does Toshiba cite
to caselaw holding that a known class of computer programs fails to have sufficient structure.
Like “circuit” or “processor,” the definition of “scheduler” as “a computer program designed to
perform functions such as scheduling, initiation, and termination of jobs” implicates a general
class of “structures,” i.e. certain types of computer programs. See Linear Tech. Corp. v. Impala
Linear Corp., 379 F.3d 1311, 1320 (Fed. Cir. 2004); Syncpoint Imaging, LLC v. Nintendo of Am.
Inc., No. 215-CV-00247-JRG-RSP, 2016 WL 55118, at *19–21 (E.D. Tex. Jan. 5, 2016).
Blue Spike does not appear to dispute that the term “memory scheduler” in the context of
the patents is a coined term. Toshiba, meanwhile, argues that because the term “memory
scheduler” is a coined term (and the term “scheduler” allegedly fails to connote structure),
“memory scheduler” must be a nonce word. Just because a term is coined, however, does not
automatically make it a nonce word. A review of the claims indicates that the patent applicants
refer to a “memory scheduler” as a type of “scheduler” as that term is understood in the field of
computer technology.
For instance, Claim 10 of the ’719 Patent recites, inter alia, “wherein said executable
code resources comprise a memory scheduler and other executable code resources . . . wherein
said memory scheduler is designed to shuffle said other executable code resources in said
memory; and wherein said memory scheduler is designed to modify a stack frame in said
memory.” Similarly, Claim 1 of the ’719 Patent recites, inter alia, “wherein said application
15
software comprises (1) a memory scheduler code resource and (2) other code resources; wherein
said application software is designed to call said memory scheduler code resource . . . .” The
’569 Patent claims refer to a “memory scheduler” only in the context of dependent claims, but
likewise indicate that a memory scheduler is a unique computer program. See, e.g., ’569 Patent,
Claim 17 (“The method of claim 16, further comprising the step of modifying the software
application to direct a call to an executable code resource to a memory scheduler.”); id. at Claim
18 (“The method of claim 17, wherein said step of intermittently relocating each of the plurality
of executable code resources is performed in response to a call to an executable code resource
received by the memory scheduler.”). The claims provide a sufficient description of the memory
scheduler’s operations such that, in combination with the structure-connoting term “scheduler,”
sufficient structural meaning is conveyed to a person of skill in the art. See Linear Tech. Corp. v.
Impala Linear Corp., 379 F.3d 1311, 1320 (Fed. Cir. 2004) (finding that the term “circuit” had
an understood meaning in the art and was not a means-plus-function term when it was coupled
with sufficient description of the circuit’s operation).
The specification further describes the term “memory scheduler”:
Under the present invention, the application contains a special code resource
which knows about all the other code resources in memory. During execution
time, this special code resource, called a "memory scheduler," can be called
periodically, or at random or pseudo random intervals, at which time it
intentionally shuffles the other code resources randomly in memory, so that
someone trying to analyze snapshots of memory at various intervals cannot be
sure if they are looking at the same code or organization from one "break" to the
next. This adds significant complexity to their job. The scheduler also randomly
relocates itself when it is finished. In order to do this, the scheduler would have to
first copy itself to a new location, and then specifically modify the program
counter and stack frame, so that it could then jump into the new copy of the
scheduler, but return to the correct calling frame. Finally, the scheduler would
need to maintain a list of all memory addresses which contain the address of the
scheduler, and change them to reflect its new location.
16
’569 Patent 8:1–19 (emphasis added).
As evident from this passage, the applicants first
introduce the “memory scheduler” and subsequently refer to it as simply a “scheduler”, again
showing that the applicants intend a “memory scheduler” to be a type of “scheduler” as that term
is understood in the field of computer technology. The patent applicants also specifically define
a “memory scheduler” as special code resources of an application, which knows about other code
resources in memory. Further, the applicants indicate that a “memory scheduler” can adjust the
other code resources. See id. This disclosure provides sufficient information such that a person
of ordinary skill in the art would understand the “structure” associated with the term “memory
scheduler.” Although Toshiba appears to challenge the specification’s definition of the memory
scheduler as a type of special code resource, the parties did not request construction of the term
“special code resource,” a term that also appears in the claims.3
Accordingly, the Court finds that the term “memory scheduler” is not subject to § 112 ¶ 6
and should be construed as “special code resources of an application, which knows about other
code resources in memory.”
c. copy protecting a software application
Claim Term
Plaintiffs’ Proposal
Defendants’ Proposal
“copy protecting a
software
application”
Plain and ordinary
“protecting a software application
from unauthorized copying or the
use of unauthorized copies”
(’569 Patent, Claim
16)
Alternate construction:
“protecting against the
unauthorized copying,
unauthorized use, or unintended
use of a software application”
3
The term “special code resource” was construed in the Huawei Order as “one or more compiled functions or
procedures.” Huawei Order, at 12.
17
The main dispute between the parties is whether “copy protection” is limited to
protecting a software application from the unauthorized copying or use of unauthorized copies.
Blue Spike contends that copy protection in the context of the Asserted Patents is broader and
also includes “attempts at memory capture or object code analysis,” “modifying, in an
unintended manner, the functioning of the application,” “attacks at disabling the system,” and
“attempts to tamper” with the software. (Doc. No. 29, at 5–6 (citing ’569 Patent, 2:21-26; 3:3740).) Blue Spike states that copy protection also applies to original works, as evidenced by the
fact that it is alternatively referred to as “content protection” or “copyright protection.” (Id. at 6.)
Blue Spike further argues that the Court in Huawei mistook Blue Spike’s statements at the
Markman Hearing for full agreement to the defendant’s proposed construction in that case—the
same construction as Toshiba’s proposed construction here—when there was “no agreement.”
(Id.) Blue Spike argues, without explanation, that the construction in Huawei has “proven
inadequate.” (Id.)
Toshiba contends that Blue Spike agreed to the construction proposed and adopted by the
Court in the Huawei case. (Doc. No. 32, at 10.) Toshiba contends that the ’569 Patent uses the
term “copy protecting” in accordance with its plain and ordinary meaning, i.e., to protect a
software application from unauthorized copying. (Id. (citing ’569 Patent, at 4:49–53, 5:51–57,
713–17 (“distribution and exchange of content would be made more secure from unauthorized
copying”; the disclosed invention prevents “unauthorized copies” and prevents hackers from
“forc[ing] the application program to run as an unauthorized copy.”).) Toshiba argues that the
’569 Patent incorporates by reference a patent that describes “copy protection” as preventing
unauthorized copies. ’569 Patent 2:34–44 (citing U.S. Patent No. 5,613,004); see also ’004
Patent, at 2:57–60.
Toshiba also contends that during prosecution of the ’569 Patent the
18
applicants argued that “a significant benefit of the claimed invention” is that it protects software
from unauthorized copying. (Doc. No. 32, at 11 (citing Doc. No. 32, Ex. 8 (’569 Patent
prosecution history, Response to Office Action dated July 23, 1997), at 2–3).) Toshiba contends
that Blue Spike provides no explanation as to why the “prior [Huawei] construction has proven
inadequate.” (Id. at 11-12.)
On reply, Blue Spike reiterates that Toshiba’s proposal is too limiting. (Doc. No. 33, at
6–7 (citing ’569 Patent, at 2:21-26).) Blue Spike also reiterates that the Court in Huawei
“misperceived an agreement between the parties.” (Id. at 7 n.10.) Blue Spike contends that
during the Markman Hearing in the Huawei case, Blue Spike continued to argue that defendants’
construction misconstrued “‘copy’ as meaning ‘copying’” rather than “copy as the copy of the
software.” (Id.)
In Huawei, the Court found the term “copy protecting a software application” should be
construed (as opposed to being left with no construction) in order avoid jury confusion.
The
Huawei Order construed the term as “protecting a software application from unauthorized
copying or the use of unauthorized copies” based on a perceived agreement between the parties
at the Markman Hearing. Huawei Order, at 5. In other words, the Court ultimately deemed it
was unnecessary to conduct a detailed analysis of the intrinsic record with respect to this term.
Meanwhile, in this case, the parties have clearly maintained disagreement with respect to their
understanding of the proper construction of the term “copy protecting a software application.”4
Thus, the Court proceeds to conduct its own analysis of the record in determining its construction
of this term. Whether or not Blue Spike actually agreed to the construction in the Huawei Order
is inconsequential to the analysis.
4
Blue Spike has not objected to construction of this term on the basis that it appears in the preamble of Claim 16.
Thus, the Court does not consider this issue in its analysis.
19
The ’569 Patent specification indicates that “copy protecting a software application” has
a broader meaning than simply protecting a software application from unauthorized copying or
the use of unauthorized copies. For example, the specification states:
It is also desirable to randomly reorganize program memory structure
intermittently during program run time, to prevent attempts at memory capture or
object code analysis aimed at eliminating licensing or ownership information, or
otherwise modifying, in an unintended manner, the functioning of the application.
’569 Patent, at 2:21-26. In other words, the ’569 Patent contemplates that a purpose of the
invention is to prevent hackers from analyzing or modifying key security portions of software
code. There is no indication that the Asserted Patents are solely limited to protecting against
analyzing or modifying copies of software. The specification likewise states:
Note that the application can be copied in an uninhibited manner, but must
contain the license code issued to the licensed owner, to access its essential code
resources. The goal of the invention, copyright protection of computer code and
establishment of responsibility for copies, is thus accomplished.
’569 Patent, at 6:32–37 (emphasis added). Other passages of the specification similarly refer to
“modifying, in an unintended manner, the functioning of the application,” “attacks at disabling
the system,” and “attempts to tamper” with software code. ’569 Patent, at 2:21–26; 3:37–40.
Thus, again, the ’569 Patent contemplates that copy protection requires protection of the original
code itself, not just “responsibility for copies.”
Despite the fact that Blue Spike cites many of these portions of the specification in its
opening brief, Toshiba does not address them in its responsive claim construction brief. Instead,
Toshiba argues that (1) “[t]he ’569 patent specification uses [‘copy protecting’] in accordance
with its plain and ordinary meaning,” and (2) that plain and ordinary meaning is “to protect a
software application from unauthorized copying.” (Doc. No. 32, at 10.) Based on a review of
the specification, including the passages cited above, these arguments are unpersuasive.
20
Nor does the prosecution history of the ’569 Patent provide a basis to limit the term
“copy protection” as Toshiba requests. In distinguishing a prior art reference, Houser, the patent
applicants stated:
Houser discloses an electronic document verification system…thereby enabling a
user to ‘sign’ the document. … Unlike Houser, which deals only with the
protection of electronic documents…claim 13 is directed to a method for copy
protection of computer software … Application of Houser to computer software
would thus fail to achieve a significant benefit of the claimed invention; namely,
rendering an unauthorized copy of the computer software effectively
inoperable.
(Doc. No. 32, Ex. 8 (’569 Patent prosecution history, Response to Office Action dated July 23,
1997), at 2–3 (emphasis added)).)
The patent applicants’ statements are a far cry from
disclaimer with respect to the term “copy protecting.”
Instead, the patent applicants
distinguished Houser as disclosing a system allowing users to sign electronic documents.
Further, the applicants state that “a significant benefit” of the claimed invention relates to
unauthorized copies; not the only benefit. The Asserted Patents thus contemplate that “copy
protection” means more than simply protecting copies.
Given the parties’ conflicting views of the “plain and ordinary” meaning of the term,
however, a construction of “copy protection” is necessary.
The Court adopts the same
construction as Huawei’s tentative construction: “protecting a software application from
unauthorized copying or unauthorized use.” Blue Spike further requests that the Court include
the phrase “unintended use” in the construction of this term. However, the phrase “unauthorized
use” already covers, to some extent, the concept of “unintended use.” The phrase “unintended
use” also goes further to imply a level of accidental use. The ’569 Patent, however, does not
reference protection against accidental use of a software application. Rather, each of the ’569
Patent examples addresses concerns of hackers intentionally tampering with software
21
applications or copies of software in one form or another.
Thus, including the phrase
“unintended use” in the Court’s construction would be, to some extent, redundant and, to some
extent, inappropriate.
Accordingly, the Court construes the term “copy protecting a software application” as
“protecting a software application from unauthorized copying or unauthorized use.”
d. during execution of the software application
Claim Term
Plaintiffs’ Proposal
“during execution
of the software
application”
Plain and ordinary
(’569 Patent, Claim
16)
Defendants’ Proposal
“while the software application is
running”
Alternate construction:
“the time between when an
application begins and ends”
Blue Spike argues that the term “during execution of the software application” should be
understood by its plain and ordinary meaning. (Doc. No. 29, at 7.) Specifically, Blue Spike
argues that the plain and ordinary meaning of “execution” encompasses the “loading” of an
application. (Id. at 7–8 (citing Doc. No. 29, Ex. 5 (Microsoft Computer Dictionary, Fifth Edition,
2002) (“In programming, execution implies loading machine code of the program into memory
and then performing the instructions.”)).) Blue Spike argues that both running and loading occur
during execution, i.e., execution begins when a user double-clicks an application on a desktop
and continues even if an application goes idle, passes control to another application, “and so on.”
(Id. at 8.)
Toshiba contends that “loading” and “execution” are different claim terms, and different
claim terms are presumed to have different meanings. (Doc. No. 32, at 13.) Toshiba contends
that the preamble of Claim 16 of the ’569 Patent refers to resources that have already been
22
loaded (i.e., “plurality of code resources loaded in a memory”), and then refers to a “software
application” and “executable code resources,” indicating that the code resources have the
potential to be executed in the future (i.e., after load time). (Id.) Toshiba further notes that the
’569 Patent describes “‘intentional[] shuffl[ing]’ of executable code resources ‘[d]uring
execution time’ at ‘periodic[]’ or ‘random or pseudo-random intervals.’” (Id. (citing ’569 Patent,
at 8:1–9).) Toshiba also argues that during patent prosecution of a related patent, the applicant
equated “execution” with “running” and treated an application’s run-time separate from “system
time.” (Id. at 13.) Toshiba objects to Blue Spike’s assertion, without any citation, that doubleclicking on an application means that “an application is executed.” (Id. at 12.) Toshiba contends
that just because a “user double-clicks on an application,” which may cause the loading and the
successive executing of the application, does not mean the two concepts are the same. (Id.)
In reply, Blue Spike contends, without support, that loading is a subset of the executing
phase: when an application is executed its instructions are first loaded and then carried out.
(Doc. No. 33, at 7.) Blue Spike contends that the Court adopted this position in Huawei by
finding that “the claim does not require that loading be completed before a program is executed.”
(Id. (citing Huawei Order, at 7).) Blue Spike argues with respect to the prosecution history that
the applicants’ use of the phrase “while running” had nothing to do with the concept of “after
loading.” (Id. at 8.)
The Huawei Order addressed similar arguments to the arguments the parties make here.
In Huawei, the Court stated
Defendants are correct that the ’569 Patent treats loading and executing
differently, that loading precedes execution, and that the code resources are
intermittently relocated during software execution. For example, loading is the act
of “transfer[ring] a program from a storage device into a computer’s memory”
and executing is “run[ning] a program, carry[ing] out a command, or peform[ing]
a function.” [(Doc. No. 32, Ex. 13 (Dictionary of Computer Words, Am. Heritage
23
Dictionaries Revised Ed., at 94, 160 (1995)).)] However, the claim does not
require that loading be completed before a program is executed. Likewise, the
’569 Patent does not exclude “idle” time from “execution time.” That is, referring
to Defendants’ app example, just because the application is in the background or
waiting for an input from a user does not necessarily mean the app is not
executing. As acknowledged by Defendants, there may still be “a few things
happening.” . . . As long as the app has started to perform instructions, it could
potentially read onto this term.
Huawei Order, at 7.
The Court agrees that loading and execution are separate concepts. For
instance, Claim 16 of the ’569 Patent refers separately to “a software application executed by a
computer system” and “executable code resources loaded in a memory.” However, as the
Huawei Order makes clear, the Asserted Patents do not exclude the possibility of execution
occurring concurrently with loading.
Neither party has set forth a sufficient basis to depart from the analysis in Huawei.
However, the Court ultimately declines to follow Huawei’s construction, which matches
Toshiba’s proposed construction in this case. See Huawei Order, at 7 (construing “during
execution of the software application” as “while the software application is running”). Swapping
out “during execution” with “while running” does not add any clarity to a jury’s understanding
of this term. Further, resolution of the real dispute between the parties as to whether loading
occurs during execution is not impacted by exchanging “during execution” for “while running.”
As noted above, “loading” and “execution” are separate concepts. “During the execution” does
not encompass mere “loading.” By rejecting Blue Spike’s position with respect to loading and
execution, no further construction is necessary. See O2 Micro Int’l Ltd. v. Beyond Innovation
Tech. Co., 521 F.3d 1351, 1362 (Fed. Cir. 2008) (“district courts are not (and should not be)
required to construe every limitation present in a patent’s asserted claims.”); Finjan, Inc. v.
Secure Computing Corp., 626 F.3d 1197, 1207 (Fed. Cir. 2010) (“Unlike O2 Micro, where the
court failed to resolve the parties’ quarrel, the district court rejected Defendants’ construction.”).
24
The Court thus concludes that no construction is necessary for the term “during execution
of the software application.”
e. call
Claim Term
Plaintiffs’ Proposal
“call”
Plain and ordinary
(’569 Patent, Claims
17, 18)
Defendants’ Proposal
“Transfer of control during
execution time.”
Alternate construction:
“A statement in a computer
program that references a
subroutine or program.”
Proposal on Reply
“a transfer of control from one
software module to another,
usually with the implication that
control will be returned to the
calling module” (Doc. No. 33, at
8.)
Blue Spike contends that one of ordinary skill in the art would understand that when a
program is called, the program is triggered to perform its assigned function. (Doc. No. 29, at
14.) Blue Spike contends that Toshiba’s construction of “call” introduces confusion because an
underlying program need not always transfer control or end when making a call. (Id.) Blue
Spike further argues that Toshiba’s reference to the phrase “execution time” in the construction
of “call” “only causes additional confusion.” (Id.)
Toshiba contends that the asserted claims use the term “call” with reference to the
“memory scheduler.” (Doc. No. 32, at 20.) Toshiba argues that according to the specification,
the “memory scheduler” is only called during execution time. (Id. (citing ’569 Patent at 8:3–4).)
25
Toshiba argues that dictionaries support its proposed construction of “call” as requiring a transfer
of control. (Id.).
Blue Spike replies by noting that its proposed alternative construction aligns with one of
the dictionary definitions identified by Toshiba: “[a] transfer of control from one software
module to another, usually with the implication that control will be returned to the calling
module.” (Doc. No. 33, at 8 (citing Doc. No. 32, Ex. 16 (The IEEE Standard Dictionary of
Electrical and Electronic Terms)).)
The term “call” only appears in the specification in two places:
With respect to
“essential” code resources, the specification states:
In general, any code resource can be considered "essential" in that if the program
proceeds to a point where it must "call" the code resource and the code resource is
not present in memory, or cannot be loaded, then the program fails.
’569 Patent, at 4:60–67 (emphasis added).
With respect to the “memory scheduler,” the
specification states, “[d]uring execution time, this special code resource, called a ‘memory
scheduler,’ can be called periodically, or at random or pseudo random intervals . . . .” ’569
Patent, at 8:3–6 (emphasis added). Neither of these passages emphasizes “execution time” or
“transfer of control” specifically with regard to the concept of “calling”. In other words, while
the specification and claims may indicate the “memory scheduler” is only called during
execution time, the specification does not require that calls in their general sense only occur
during execution time. Further, including the phrase “during execution time” in the construction
of “call” in the manner that Toshiba proposes adds ambiguity.
As written, Toshiba’s
construction is unclear whether the phrase refers to the execution time of an operating system,
the application software, or the call itself.
26
Nor do either of the quoted passages of the specification require a “transfer of control”
with respect to calls. Indeed, it would be improper to impute the phrase “transfer of control” into
the construction of this term. As indicated in Toshiba’s dictionary definitions, calls may be used
to summon “subroutines,” “procedures,” or other software modules. (Doc. No. 32, Exs. 14 &
15.) There is no requirement in these definitions and no disclosure in the specification limiting
the term “call” to require a full shutdown and full transfer of control from the original program to
another subroutine, program, procedure, or module. Thus, although the “transfer of control”
language may appear in some dictionary definitions of “call,” this language alone could mislead
a fact-finder to think 1) transfer of control must occur in its entirety and 2) further, to the extent
control is transferred, it is permanently transferred.
The specification uses the term “call” in its plain and ordinary sense in the field of
computer technology. Neither party has pointed to an inherent ambiguity in the meaning of the
term “call” that would warrant construction. Rather, Toshiba’s proposal is an attempt to limit the
scope of the term “call” that is unwarranted in the context of the Asserted Patents and would be
more confusing than helpful for a jury.
The Court thus finds that no construction is necessary for the term “call”.
f. intermittently relocating
Claim Term
Plaintiffs’ Proposal
Defendants’ Proposal
“intermittently
relocating”
Intermittently Relocating
Intermittently Relocating
Plain and ordinary
“intentionally shuffling at periodic,
random or
(’569 Patent, Claims
16, 18, 19, 20)
Alternate construction 1:
“relocating one or more times”
Alternate construction 2:
“moving to a new location one
27
pseudo-random intervals”
or more times”
Proposal on Reply
“shuffling randomly, seeminglyrandomly, or non-randomly”
(see Doc. No. 33, at 9)
In their briefing, the parties submitted proposed constructions and argument with respect
to both the terms “intermittently relocating” and “relocating.” However, Claims 16, 18, 19, and
20 each recite “intermittently relocating”; none of them recite simply “relocating.” Thus, the
Court will only address the parties’ arguments relating to “intermittently relocating.”
Blue Spike contends that Toshiba replaces “intermittently relocating,” a plainly
understood phrase, with hyper-technical language that is likely to confuse a jury. (Doc. No. 29,
at 9.) Blue Spike specifically objects to the use of the word “intentionally” in Toshiba’s
construction. (Id. at 10.) Blue Spike contends that the specification refers to intentionality in the
context of the memory scheduler and merely indicates that the memory scheduler shuffles code
in memory when called. (Id.)
Blue Spike argues that including the word “intentional” in the
construction of “intermittently relocating” risks importing an additional limitation into Claim 16
of the ’569 Patent, which does not claim a “memory scheduler”. (Id. at 10–11.) Blue Spike also
sets forth alternative proposed constructions that clarify “intermittently relocating” can occur one
or more times.
(Id. at 11 (citing Huawei Order, at 9 (holding with respect to the term
“intermittently relocating” that “[t]he patentee’s statement [in prosecution history] could include
multiple shuffles but does not necessarily exclude a single shuffle.”)).)
Toshiba argues that the Huawei Order’s interpretation of “intermittently relocating” as
covering a single shuffle is incorrect and that the term should require more than one shuffle.
(Doc. No. 32, at 21 (citing Huawei Order, at 9).) Toshiba contends that the term “relocating”
28
alone could include a single shuffle, but the addition of “intermittently” demonstrates that the
patent applicants intended the term to encompass only multiple shuffles. (Id. at 21.) Toshiba
argues that the term “intervals” as used in its plural form in the specification, prosecution history,
and Huawei Order further conveys “the meaning of more than one interval,” and thus at least two
shuffles. (Id. at 22 (citing ’569 Patent, at 8:3–7; Doc. No.32, Ex. 17 (’569 Patent prosecution
history, Response to Final Office Action June 26, 1997), at 7; Huawei Order, at 9).) Toshiba
also specifically argues that the prosecution history, relied on in the Huawei Order, shows that
the applicants distinguished prior art systems on the basis that they did not rearrange memory in
an intentional effort to secure copy protection. (Id. at 22 (citing ’569 Patent, at 7:30–36).)
Toshiba argues that the term is not “readily understood” because 1) the examiner needed
clarification as to what “intermittently relocating” meant, and 2) in Huawei, the Court noted that
the term has “inherent ambiguity.” (Id. at 23 (citing Doc. No. 32, Ex. 18 (’569 Patent prosecution
history, Office Action May 22, 1997), at 2 (“it is unclear what is meant by ‘relocating’ and by
‘intermittently relocating’ in context.”); Huawei Order, at 9).)
Blue Spike replies by arguing that “shuffling one or more times” is sufficient to capture
the meaning of the term “intermittently relocating.” (Doc. No. 33, at 9.) Blue Spike proposes an
alternative construction of “shuffling randomly, seemingly-randomly, or non-randomly.” (Id.)
The Huawei Order construed the term “intermittently relocating” as “intentionally
shuffling at periodic, random, or pseudo-random intervals.” Huawei Order, at 10. This is the
same construction that Toshiba proposes in this case.
Blue Spike does not provide a sufficient explanation for why its alternative proposed
phrasing of “randomly, seemingly-randomly, or non-randomly” adds more clarity than the
phrasing “periodic, random, or pseudo-random.” The parties do not appear to have a serious
29
dispute on this point, and the Court finds no basis to depart from the “periodic, random, or
pseudo-random” phrasing used in both the specification and in Huawei’s construction. See ’569
Patent, 8:3–10; (see also Doc. No. 32, Ex. 17 (’569 Patent prosecution history, Response to Final
Office Action June 26, 1997), at 7 (referring to this passage of the specification to define
“intermittently relocating.”).) The two main disputes remaining between the parties are thus 1)
whether “intermittently relocating” requires intentional shuffling and 2) whether “intermittently
relocating” requires more than one shuffle.
The Huawei Order refers to Blue Spike’s dispute with the term “intentional” in the
construction of “intermittently relocating,” but does not address the dispute at length. See
Huawei Order, at 9. The Order does quote from the relevant portion of the ’569 Patent stating:
Under the present invention, the application contains a special code resource
which knows about all the other code resources in memory. During execution
time, this special code resource, called a “memory scheduler,” can be called
periodically, or at random or pseudo random intervals, at which time it
intentionally shuffles the other code resources randomly in memory, so that
someone trying to analyze snapshots of memory at various intervals cannot be
sure if they are looking at the same code or organization from one “break” to the
next.
’569 Patent at 8:1–10. The Order also notes, “[d]efendants further clarified that ‘intentional’
does not require user initiated relocating or shuffling, addressing Blue Spike’s concern on this
point.” Huawei Order, at 9.
Blue Spike argues, however, that the quoted portion of the
specification merely indicates that the memory scheduler intentionally shuffles other code
resources; it does not mean that the term “intermittently relocating” requires intentional
shuffling. (Doc. No. 29, at 10.) Blue Spike also argues that including the term could lead to jury
confusion “as to whom or what is intending the shuffling to occur.”
arguments are well-taken.
(Id. at 11.)
These
Construing “intermittently relocating” to require “intentional
shuffling” opens up the potential for jury confusion by implying a level of intentionality that the
30
Asserted Patents do not require.
Toshiba responds by noting that the Asserted Patents
distinguish the claimed invention from prior art systems that “rearrange certain portions of
memory during ‘system time’. . . Typically, this is done in low memory systems, to maintain
optimal memory utilization.” (Doc. No. 32, at 22 (citing ’569 Patent, at 7:30–36).) However,
Claim 16 of the ’569 Patent specifically requires that the code resources are intermittently
relocated “during execution of the software application.” Thus, the claims on their face already
distinguish from these prior art scenarios. There is no basis to import “intentional shuffling” into
the meaning of “intermittently relocating.”
Huawei did analyze whether “intermittently relocating” requires more than one shuffle.
See Huawei Order, at 9. The Huawei Order found that there was not a clear disclaimer or
disavowal in the prosecution history excluding a single shuffle. Id. According to Huawei, “[t]he
patentee’s statement [during prosecution history] could include multiple shuffles but does not
necessarily exclude a single shuffle. For example, a shuffle at a random time would be consistent
with the patentee’s statement.” Id.
Huawei was specifically referring to a portion of the
prosecution history where the applicants stated:
Applicants respectfully direct the Examiner’s attention to the disclosure at
[Col.8:1-19] of the Specification, which describes an embodiment of the present
invention wherein the code resources are “shuffled” in memory at periodic,
random or pseudo-random intervals. See also [Col. 3:38-41 of the] Specification,
(“Attempts to tamper or ‘patch’ substitute code resources can be made highly
difficult by randomizing the location of said resources in memory on an
intermittent basis . . .”). Given the foregoing, the Applicant respectfully submits
that the language of claim[] 28 would be clear to a person of ordinary skill in the
art.
(Doc. No. 32, Ex. 17, at 7.) This Court respectfully disagrees with Huawei’s interpretation of
“intermittently relocating” as not excluding a single shuffle for two reasons. First, both the
specification and the prosecution history refer to “intervals,” not the singular term “interval.”
31
(See id.); see also ’569 Patent, at 8:1–19. Second, the plain meaning of the term “intermittently”
(and the phrase “on an intermittent basis”) implies that an event occurs on a repeated basis:
something that happens only once has not occurred “intermittently.” (See Doc. No. 29, Ex. 5
(Microsoft Dictionary, 5th Ed.) (“intermittent: adj. pertaining to something, such as a signal or
connection, that is not unbroken, but occurs at periodic or occasional intervals”), at 280.) If the
applicants intended to encapsulate just a single movement of memory, they could have easily
drafted Claims 16, 18, 19, and 20 of the ’569 Patent to say simply “relocating”, “randomizing”,
or “shuffling.” The Court thus finds that “intermittently relocating” requires more than one
shuffle.
Accordingly, the Court construes “intermittently relocating” as “shuffling at periodic,
random, or pseudo-random intervals.”
g. shuffle & randomize
Claim Term
Plaintiffs’ Proposal
Defendants’ Proposal
“shuffle”
Plain and ordinary
(’719 Patent, Claim
10, 11, 12)
“Randomly reorganize during
program run time.”
Alternate construction:
“move a portion of a sequence to
a new location in a sequence”
Proposal on Reply
“rearrange” or “reorganize” (See
Doc. No.33, at 9 n.12)
Claim Term
Plaintiffs’ Proposal
“randomize”
“employ random selection”
(’719 Patent, Claim
22)
Proposal on Reply
“rearrange” or “reorganize” (See
Doc. No. 33, at 9 n.12)
32
Defendants’ Proposal
“Randomly reorganize during
program run time.”
Blue Spike objects to Toshiba’s constructions as applying the same definitions for
“randomize,” and “shuffle.” (Doc. No. 29, at 15.) Blue Spike contends the terms are not used
synonymously. (Id.) Blue Spike also objects to Toshiba’s constructions (1) as being more
confusing than the original terms, (2) as improperly importing the idea of “during program run
time,” (similar to Blue Spike’s objection to “execution time” in the “call” term above), and (3) as
construing “shuffle” and “randomize” the same, even though both terms are used in the same
claims. (Id.)
With respect to the term “shuffle,” Blue Spike contends that its alternative
construction as “move a portion of a sequence to a new location in a sequence” embodies the
idea that a collection of code resources may be moved to different locations and affords “shuffle”
its own meaning rather than sharing it with disparate terms. (Id.) With respect to the term
“randomize,” Blue Spike asserts that the plain and ordinary meaning is to “employ random
selection.” (Id.)
Toshiba acknowledges that, as a default, different claim terms have different meanings.
(Doc. No. 32, at 24.) Toshiba contends, however, that a court can construe different terms to
have the same meanings where the patent and prosecution history do not reveal a difference
between the terms. (Id. (citing Fargo Elecs., Inc. v. Iris Ltd., Inc., No. 04-1017 JRT/FLN, 2005
WL 3241851, at *14 (D. Minn. Nov. 30, 2005), aff'd, 287 F. App'x 96 (Fed. Cir. 2008) (“In so
doing, the Court is aware that it is defining different terms to have essentially the same meaning.
Although a patentee's use of different terms normally indicates that it intended those terms to
carry different meanings, a reading of the patent and prosecution history does not reveal what
that difference might be in this case”)).) Toshiba contends that “the core of the invention
disclosed in the ’569 Patent is the shuffling of code resources randomly in memory to prevent
33
unauthorized copying and increase protection.” (Id.) Toshiba contends that the patent refers to
the shuffling process “in many ways throughout the patent – relocate, randomize, shuffle – but
all of these terms have the same meaning.” (Id.) Further, Toshiba contends that the Asserted
Patents emphasize “during program run time” and “during execution time,” consistent with
Toshiba’s construction. (Id. at 24–25 (citing ’569 Patent, at 2:21–26, 8:3–7).)
On reply, Blue Spike alternatively proposes constructions of the terms “shuffle” and
“randomize” as either “rearrange” or “reorganize.” (Doc. No. 33, at 9 n.12.) Blue Spike
contends that “anyone who has shuffled a deck of cards understands that to ‘shuffle’ means to
‘rearrange’ or ‘reorganize.’” (Id. at 9.) Blue Spike contends that shuffling implies movement of
multiple items. (Id.) Blue Spike contends that unlike “randomize,” the term “shuffle” does not
require random movement. (Id. at 9–10 (citing ’569 Patent, 8:6–7 (“shuffles the other code
resources randomly in memory.”)).) Blue Spike argues that “during program run time” does not
even match Toshiba’s cited portion of the specification, which states “[d]uring execution time.”
(Id. at 10.) Blue Spike argues that while some of the claims specifically recite “during execution
time,” others do not, making it inappropriate to import the limitation into the “shuffle” and
“randomize” terms. Id. at 10–11.
As with the term “call,” there is not a clear disclaimer or disavowal in the intrinsic record
with respect to the terms “shuffle” and “randomize” such that the terms should be limited to only
occurring “during execution time.”
Although embodiments in the specification refer to
“shuffling” or “relocating” as occurring “during execution time,” (see, e.g., ’569 Patent, at 2:21–
26; 8:3–7), “particular embodiments and examples appearing in the specification will not
generally be read into the claims.” Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560,
1571 (Fed. Cir. 1988); see also Phillips, 415 F.3d at 1323. Indeed, as Blue Spike notes, only
34
some of the claims of the Asserted Patents that refer to “shuffling,” “randomizing,” and
“relocating,” also claim “during execution time.”
The parties seem to agree at a high level that all the terms relate to “rearranging” or
“reorganizing.” However, it would be inappropriate to construe both “shuffle” and “randomize”
as “randomly reorganize.” The specification uses the term “shuffle” in a manner that does not
always require “random” shuffling. For example, the specification states “shuffle the other code
resources randomly.” ’569 Patent, at 8:3–7. By specifically indicating that the shuffling occurs
randomly in this embodiment, the specification implicitly acknowledges that “shuffling” is not
inherently random. See Phillips, 415 F.3d at 1314 (“To take a simple example, the claim in this
case refers to “steel baffles,” which strongly implies that the term “baffles” does not inherently
mean objects made of steel.”). On the other hand, in some instances the specification refers to
“randomly reorganize[ing].” ’569 Patent, 2:21–22; 7:22–24 (“[a] second method according to
the present invention is to randomly re-organize program memory structure to prevent attempts
at memory capture or object code analysis.”). The word “randomize” is simply a conjugation of
the words “randomly” and “reorganize”; by its very nature, the word “randomize” implies that
reorganization is random.
The Court thus construes “shuffle” as “reorganize” and construes “randomize” as
“randomly reorganize.”
CONCLUSION
For the foregoing reasons, the Court adopts the constructions set forth above
.
35
So ORDERED and SIGNED this 28th day of June, 2017.
36
Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.
Why Is My Information Online?