ROY-G-BIV Corporation v. ABB, Ltd. et al
Filing
196
MEMORANDUM OPINION AND ORDER. The Court adopts the constructions set forth in this opinion for the terms of the patents in suit. Signed by Magistrate Judge Zack Hawthorn on 07/25/13. (mll, )
IN THE UNITED STATES DISTRICT COURT
FOR THE EASTERN DISTRICT OF TEXAS
TYLER DIVISION
ROY-G-BIV CORP.
§
§
v.
§
§
ABB, Ltd., ABB INC., MEADWESTVACO §
TEXAS, LP, and MEADWESTVACO
§
CORP.
§
§
§
ROY-G-BIV Corp.
§
§
v.
§
§
HONEYWELL INTERNATIONAL, INC. §
and MOTIVA ENTERPRISES, LLC
§
§
§
ROY-G-BIV CORP.
§
§
v.
§
§
SIEMENS CORP., et al.
§
NO. 6:11-CV-622 (Lead Case)
NO. 6:11-CV-623
NO. 6:11-CV-624
CLAIM CONSTRUCTION MEMORANDUM OPINION AND ORDER
These cases are assigned for trial to the Honorable Leonard Davis, United States Chief
District Judge, and are referred to the undersigned United States Magistrate Judge for claim
construction purposes, including Defendants’ Motion for Summary Judgment of Indefiniteness.
(Doc. No. 158.) On June 19, 2013, the Court held a hearing to determine the proper construction
of the claim terms in U.S. Patent Nos. 6,513,058; 6,516,236; 6,941,543; and 8,073,557, and to hear
argument on the Defendants’ Motion for Summary Judgment. See (Transcript, Doc. No. 183.)
After considering the arguments made by the parties at the hearing and in the parties’ claim
construction and summary judgment briefing (Doc. Nos. 151, 157, 167, 168, 169, 171, 174, 175),
the Court adopts the constructions set forth below. See also Appendix A.
Also before the Court is the Defendants’ Joint Motion for Summary Judgment of
Indefiniteness. (Doc. No. 168.) While the terms underlying that Motion are construed in this
Order, the undersigned will also enter a separate report recommending that Chief Judge Davis
deny the Defendants’ Motion.
2 of 64
TABLE OF CONTENTS
I. BACKGROUND ..............................................................................................................................4
II. APPLICABLE LAW .......................................................................................................................5
A. General Principles of Claim Construction .........................................................................5
B. Effect of Prior Claim Construction .....................................................................................7
C. Indefiniteness ......................................................................................................................8
III. CONSTRUCTION OF AGREED UPON TERMS ..............................................................................10
IV. CONSTRUCTION OF DISPUTED TERMS .....................................................................................11
A. “Motion Control” .............................................................................................................11
B. “Motion Control Operations” ..........................................................................................12
C. “Primitive Operations” and “Non-Primitive Operations” ..............................................15
D. “Motion Control Device” .................................................................................................28
E. “Application Program” ....................................................................................................30
F. “Driver Functions” ...........................................................................................................35
G. “Core Driver Function” and “Extended Driver Function” ............................................39
H. “Network” ........................................................................................................................45
V. CONSTRUCTION OF DISPUTED MEANS-PLUS-FUNCTION TERMS ...............................................46
A. “Means for Determining a Driver Unit System Employed by the Software Drivers” .....48
B. “Means for Converting an Application Unit System” ......................................................51
C. “Means for Generating Command Data Strings” ............................................................53
D. “Means for Parsing Response Data Strings”...................................................................55
E. “Stream Control Means for Communicating the Control Commands” ...........................58
VI. CONCLUSION ...........................................................................................................................61
APPENDIX A: COURT’S CONSTRUCTION OF CLAIM TERMS .............................................................62
3 of 64
I. Background
The Plaintiff Roy-G-Biv Corp. (“RGB”) sued the following Defendants for infringement
of U.S. Patent Nos. 6,513,058 (“the ‘058 Patent”), 6,516,236 (“the ‘236 Patent”), 6,941,543 (“the
‘543 Patent”), and 8,073,557 (“the ‘557 Patent”): ABB, Inc., Honeywell International, Inc.,
MeadWestvaco Corp., MeadWestvaco Texas, LP, Motiva Enterprises, LLC, Siemens AG, Inc.,
Siemens Corp., Siemens Industry, Inc., Siemens Product Lifecycle Management Software, Inc.,
and Siemens Product Lifecycle Management Software II (US), Inc. 1 RGB asserts claims 1–5 of
the ‘058 patent, claims 1–10 of the ‘236 patent, claims 5–16 of the ‘543 patent, and claims 16–30
and 46–59 of the ‘557 patent.
The RGB Patents relate generally to “motion control” technology, in which the operation
of motorized mechanical devices (“motion control devices”) is controlled with software. More
specifically, the RGB Patents are directed to a system that allows an application program to
communicate with and control any one of a group of supported motion control devices that may
speak different “languages.” RGB describes the system in a three-tiered manner, involving an
application program that generates control commands, “middleware” that translates control
commands into a language understandable by software drivers, and device-specific software
drivers that directly communicate with and control particular motion control devices.
RGB previously asserted three of the RGB Patents in ROY-G-BIV Corp. v. Fanuc Ltd.,
(“Fanuc”), No. 2:07-CV-418 (E.D. Texas). In that case, Judge David Folsom construed many of
the same patent terms that are at issue in the present action. See Fanuc, No. 2:07-CV-418, 2009
U.S. Dist. LEXIS 127428 (E.D. Tex. Aug. 25, 2009) (construing claim terms in the ‘058, ‘236, and
‘543 Patents as well as U.S. Patent No. 5,691,897).
1. This order refers to the four asserted patents collectively as “the RGB Patents” and all defendants
collectively as “the Defendants.”
4 of 64
II. Applicable Law
A. General Principles of Claim Construction
“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) (en banc) (quoting Innova/Pure Water Inc. v. Safari Water Filtration Sys., Inc.,
381 F.3d 1111, 1115 (Fed. Cir. 2004)). Courts generally give claim terms their ordinary and
customary meaning as understood by one of ordinary skill in the art at the time of the invention.
Id. at 1312–13. To determine the meaning of claims, courts begin by examining the intrinsic
evidence. Bell Atl. Network Servs., Inc. v. Covad Commc’ns Group, Inc., 262 F.3d 1258, 1267
(Fed. Cir. 2001); see also Phillips, 415 F.3d at 1313–14; C.R. Bard, Inc. v. U.S. Surgical Corp.,
388 F.3d 858, 861 (Fed. Cir. 2004). The intrinsic evidence includes the claims themselves, the
specification, and the prosecution history. Bell Atl. Network Servs., Inc., 262 F.3d at 1267; see
also Phillips, 415 F.3d at 1314; C.R. Bard, Inc., 388 F.3d at 861.
“[T]he claims themselves provide substantial guidance as to the meaning of particular
claim terms.” Phillips, 415 F.3d at 1314. First, a term’s context in the asserted claim can be
highly instructive. Id. Other asserted or unasserted claims may likewise provide guidance on a
term’s meaning since claim terms are typically used consistently throughout a patent.
Id.
Differences among claims can also assist in understanding a term’s meaning. Id. For example,
when a dependent claim adds a limitation to an independent claim, it is presumed that the
independent claim does not include the limitation. Id. at 1314–15.
Claims must also be read in view of the specification. Id. at 1315 (quoting Markman v.
Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995) (en banc)). “[T]he specification
‘is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the
5 of 64
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)). This is true because a patentee may
define her own terms, give a claim term a different meaning than the term would otherwise
possess, or disclaim or disavow the claim scope. Id. at 1316. In these situations, the inventor’s
lexicography governs. Id. Further, the specification may serve to 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. v.
Ficosa N. Am. Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002). However, “particular embodiments
and examples appearing in the specification will not generally be read into the claims.” Comark
Commc’ns, Inc. v. Harris Corp., 156 F.3d 1182, 1187 (Fed. Cir. 1998) (quoting Constant v.
Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed. Cir. 1988)) (internal quotation marks
omitted); see also Phillips, 415 F.3d at 1323.
The prosecution history is another resource that courts should employ when defining claim
terms. Phillips, 415 F.3d at 1317. The prosecution history “consists of the complete record of
the proceedings before the PTO and includes the prior art cited during the examination of the
patent.” Id. “Like the specification, the prosecution history provides evidence of how the PTO
and the inventor understood the patent.” Id.; see also 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.”). But, because it represents “an ongoing negotiation
between the PTO and the applicant, rather than the final product of that negotiation,” the
prosecution history often lacks clarity and proves less useful for claim construction purposes than
the specification. Phillips, 415 F.3d at 1317. The well-established doctrine of prosecution
disclaimer “preclud[es] patentees from recapturing through claim interpretation specific meanings
6 of 64
disclaimed during prosecution.” Omega Eng’g Inc. v. Raytek Corp., 334 F.3d 1314, 1323 (Fed.
Cir. 2003).
Although extrinsic evidence can be useful, it is “less significant than the intrinsic record in
determining the legally operative meaning of claim language.” Phillips, 415 F.3d at 1317
(quoting C.R. Bard, Inc. v. U.S. Surgical Corp., 388 F.3d 858, 862 (Fed. Cir. 2004)) (internal
quotation marks omitted). Extrinsic evidence “consists of all evidence external to the patent and
prosecution history, including expert and inventor testimony, dictionaries, and learned treatises.”
Id. (quoting Markman v. Westview Instruments, Inc., 52 F.3d 967, 980 (Fed. Cir. 1995) (en banc))
(internal quotation marks omitted).
Technical dictionaries and treatises may help a 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 the term is used in the patent. See id. at 1318. Similarly, expert testimony may aid a
court in understanding the underlying technology and determining the particular meaning of a term
in the pertinent field, but an expert’s conclusory, unsupported assertions as to a term’s meaning is
entirely unhelpful to a court. Id. Generally, extrinsic evidence is “less reliable than the patent
and its prosecution history in determining how to read claim terms.” Id.
B. Effect of Prior Claim Construction
As indicated above, many of the claim terms at issue were previously construed by Judge
Folsom in a prior case where the Plaintiff asserted three of the patents in suit. Prior claim
construction proceedings involving the same asserted patents are “entitled to reasoned deference
under the broad principals of stare decisis and the goals articulated by the Supreme Court in
Markman, even though stare decisis may not be applicable per se.”
Maurice Mitchell
Innovations, LP v. Intel Corp., No. 2:04-CV-450, 2006 WL 1751779, at *4 (E.D. Tex. June 21,
7 of 64
2006) (Davis, J.). However, previous constructions are not compelling or binding: a court still
conducts an independent evaluation during claim construction proceedings. See, e.g., Negotiated
Data Solutions, Inc. v. Apple, Inc., No. 2:11-CV-390, 2012 WL 6494240, at *5 (E.D. Tex. Dec.
13, 2012) (Gilstrap, J.); Burns, Morris & Stewart Ltd. P’ship v. Masonite Int’l Corp., 401 F. Supp.
2d 692, 697 (E.D. Tex. 2005) (Clark, J.); Tex. Instruments, Inc. v. Linear Techs. Corp., 182 F.
Supp. 2d 580 (E.D. Tex. 2002) (Folsom, J.).
C. Indefiniteness
Defendants also contend that some claims at issue are invalid for indefiniteness. A patent
is presumed valid; therefore, the party seeking to invalidate a patent must overcome that
presumption. 35 U.S.C. § 282; Microsoft Corp. v. i4i Ltd. P’ship, 131 S. Ct. 2238, 2243 (2011).
The presumption places the burden on the challenging party to prove, by clear and convincing
evidence, that the patent is invalid. Microsoft Corp., 131 S. Ct. at 2243–52; United States
Gypsum Co. v. Nat’l Gypsum Co., 74 F.3d 1209, 1212 (Fed. Cir. 1996). Accordingly, close
questions of indefiniteness “are properly resolved in favor of the patentee.” Exxon Research &
Eng’g Co. v. United States, 265 F.3d 1371, 1380 (Fed. Cir. 2001).
Claims must particularly point out and distinctly claim the patentee’s invention. 35
U.S.C. § 112, ¶ 2 (2006) (“The specification shall conclude with one or more claims particularly
pointing out and distinctly claiming the subject matter which the applicant regards as his
invention.”). “Because the claims perform the fundamental function of delineating the scope of
the invention, the purpose of the definiteness requirement is to ensure that the claims delineate the
scope of the invention using language that adequately notifies the public of the patentee’s right to
exclude.” Datamize, LLC v. Plumtree Software, Inc., 417 F.3d 1342, 1347 (Fed. Cir. 2005)
(citations omitted). “The statutory requirement of particularity and distinctness in claims is met
8 of 64
only when [the claims] clearly distinguish what is claimed from what went before in the art and
clearly circumscribe what is foreclosed from future enterprise.” Id. (quoting United Carbon Co.
v. Binney & Smith Co., 317 U.S. 228, 236 (1942)) (internal quotation marks omitted).
Nonetheless, the definiteness requirement does not demand absolute clarity: only those claims
“not amenable to construction” or “insolubly ambiguous” are indefinite. Id.; see also Halliburton
Energy Servs., Inc. v. M-I LLC, 514 F.3d 1244, 1250 (Fed. Cir. 2008). A claim is insolubly
ambiguous when a person of ordinary skill in the art could not determine the bounds of the claims.
Halliburton Energy Servs., Inc., 514 F.3d at 1249.
“A determination of indefiniteness is a legal conclusion that is drawn from the court’s
performance of its duty as the construer of patent claims.” Atmel Corp. v. Info. Storage Devices,
Inc., 198 F.3d 1374, 1378 (Fed. Cir. 1999) (quoting Personalized Media Commc’ns, LLC v. Int’l
Trade Comm’n, 161 F.3d 696, 705 (Fed. Cir. 1998)) (internal quotation marks omitted).
“Indefiniteness, therefore, like claim construction, is a question of law . . . .” Id. When
determining indefiniteness, the general principles of claim construction described above apply.
Enzo Biochem, Inc. v. Applera Corp., 599 F.3d 1325, 1332 (Fed. Cir. 2010). To rule “on a claim
of patent indefiniteness, a court must determine whether those skilled in the art would understand
what is claimed when the claim is read in light of the specification.” Bancorp Servs., L.L.C. v.
Hartford Life Ins. Co., 359 F.3d 1367, 1372 (Fed. Cir. 2004).
“[A] difficult issue of claim construction does not ipso facto result in a holding of
indefiniteness.” Datamize, 417 F.3d at 1347 (citing Exxon Research & Eng’g Co. v. United
States, 265 F.3d 1371, 1375 (Fed. Cir. 2001)). “If the meaning of the claim is discernible, even
though the task may be formidable and the conclusion may be one over which reasonable persons
will disagree,” the claim is sufficiently clear to avoid invalidity on indefiniteness grounds.
9 of 64
Exxon, 265 F.3d at 1375. By finding a claim indefinite only when reasonable efforts at claim
construction prove futile, a court accords respect to the statutory presumption of validity, protects
the inventive contribution of patentees, and follows the requirement that clear and convincing
evidence be shown to invalidate a patent. Datamize, 417 F.3d at 1347–48.
III. Construction of Agreed Upon Terms
The parties agreed to the construction of the following terms:
Claims in Which
Agreed Definition
Term Appears
“driver code” ‘236 Patent, claims 1–4, 6; ‘058
“code associated with a hardware device or
Patent, claims 1, 3, 4; ‘557 Patent, group of related hardware devices, which
claims 16, 46; ‘543 Patent, claims 1, helps generate commands necessary to
5, 14
perform motion control operations
associated with at least some driver
functions”
“control
‘236 Patent, claims 1, 4, 5, 8, 9; ‘058 “command codes in hardware language,
commands” Patent, claims 1, 3, 4; ‘557 Patent, which instruct a motion control device to
claims 16, 23, 24, 26, 28, 46, 53, 54, perform motion control operations”
56, 58; ‘543 Patent, claims 1, 2, 5, 6,
13, 14, 16
“motion control ‘236 Patent, claims 1, 4, 5, 10; ‘557 “an intermediate software layer containing
component”/ Patent, claims 16, 20, 27, 46, 47, 50, component code that is separate and distinct
“motion
57
from the application program and the
component”
software driver”
“component ‘236 Patent, claim 1; ‘058 Patent, “a hardware independent function that
function”
claims 1–4; ‘557 Patent, claims 16– corresponds to a motion control operation”
20, 29, 46–50; ‘543 Patent, claims 3,
8, 13, 16
“software ‘236 Patent, claims 1–3, 7; ‘058
“one or more controller dependent software
driver”/ “driver” Patent, claims 1, 3, 4; ‘557 Patent, modules that support some core driver
claims 16, 21, 22, 27, 46, 51, 52, 55, functions and are used to control a hardware
57; ‘543 Patent, claim 1, 5, 13, 14 device or group of related hardware
devices”
“component ‘236 Patent, claim 1; ‘058 Patent, “software code in the motion control
code”
claims 1, 4; ‘557 Patent, claims 16– component that associates at least some of
19, 22, 29, 46, 48–49, 52; ‘543
the component functions with at least some
Patent, claim 16
of the driver functions”2
Terms
2. The parties agreed on this construction after filing their briefs and prior to the Markman hearing. The
parties notified the Court by phone of their agreement, and the Court confirmed that they were in agreement at the
Markman hearing. (Doc. No. 183, at 135:4–8.)
10 of 64
In view of the parties’ agreements on the proper construction of each of the identified terms, the
Court adopts the parties’ agreed-upon constructions as set forth above. 3 These agreed-upon
constructions govern in this case as to these particular terms.
IV. Construction of Disputed Terms
A. “Motion Control”
Plaintiff’s Proposed Construction
no construction needed; in the alternative,
“controlled movement”
Defendants’ Proposed Construction
control of movement of an object along a desired
path
The noun “motion control” does not appear in the claims of the asserted RGB Patents.
Instead, motion control is used as an adjective within two other claim terms that the parties have
also asked the Court to construe: “motion control operation” and “motion control device.”
Because “motion control” was not used as a separate term in the claims, the Court instructed the
parties at the Markman hearing that it did not intend to define motion control separately from the
two terms that contained it. After considering the Court’s preliminary construction of claim
terms at the Markman hearing, the Defendants stated that they no longer believed that the Court
needed to define “motion control.” See (Doc. No. 18, at 9–11.)
Accordingly, the parties and the Court being in agreement, the Court finds that it is
unnecessary to define “motion control.”
3. The parties also agreed on the construction of the term “primitive operations.” As explained more fully
below, the Court neither agrees with nor adopts the parties’ construction for this term. See infra Part IV.C.
11 of 64
B. “Motion Control Operations”4
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
“abstract operations (such as GET POSITION,
MOVE RELATIVE, or CONTOUR MOVE)
that are performed on or by a motion control
device”
hardware independent operations used to
perform motion control (such as GET
POSITION, MOVE RELATIVE, or CONTOUR
MOVE)
In Fanuc, Judge Folsom construed this term as “abstract operations (such as GET
POSITION, MOVE RELATIVE, or CONTOUR MOVE) used to perform motion control.”
Fanuc, No. 2:07-CV-418, 2009 U.S. Dist. LEXIS 127428, at *29–34 (E.D. Tex. Aug. 25, 2009).
In its Brief, RGB notes that the Fanuc construction is “correct if applied reasonably.”
(Doc. No. 151, at 9.) However, in order to preclude the Defendants from reading their proposed
definition for motion control into this term, and excluding the preferred embodiment, RGB urges
the Court to substitute “that are performed on or by a motion control device” for “used to perform
motion control.” (Id.) RGB argues that this is not a substantive change because operations
performed on or by the motion control device advance the objective of performing motion control
and thus are used to perform motion control. (Id.) Similarly, RGB also argues that “abstract”
should be used instead of “hardware independent,” in order to head off an argument that it fears the
Defendants might later make. It also states that “abstract operations” is the language used in the
specification. (Id. at 10) (citing ‘236 Patent, 7:24).
In their Brief, the Defendants argue that the specification describes motion control
operations as used to move an object along a desired path. (Doc. No. 157, at 6) (citing ‘236
Patent, 8:26–30) (“motion control operations necessary to control a motion control device to move
an object in a desired manner”). The Defendants also note that during reexamination of the ‘058
Patent, RGB described motion control operations as “operations used to perform motion control.”
4. ‘236 Patent, claims 1, 4; ‘058 Patent, claim 4; ‘557 Patent, claims 16, 46; ‘543 Patent, claims 14, 15.
12 of 64
(Id. at 9 and Ex. B, at 38.) As for “hardware independent” instead of “abstract,” the Defendants
point out that the patents use the terms interchangeably and that “hardware independent” will
likely be easier for a jury to understand. (Id. at 7.)
1. Analysis
The term “motion control operations” is used in claim 1 of the ‘236 Patent as follows:
A system for generating a sequence of control commands for controlling a selected
motion control device selected from a group of supported motion control devices,
comprising:
a set of motion control operations, where each motion control operation
is either a primitive operation the implementation of which is required to
operate motion control devices and cannot be simulated using other
motion control operations or a non-primitive operation that does not
meet the definition of a primitive operation; . . . .
‘236 Patent, claim 1 (emphasis added). This demonstrates that a motion control operation is
something that is implemented or performed. The specification confirms that motion control
operations are performed, and further explains that they are performed by motion control devices:
The motion control operations are not specifically related to any particular
motion control device hardware configuration, but are instead abstract operations
that all motion control device hardware configurations must perform in order to
function.
‘236 Patent, 7:22–26. Therefore, the claim terms and the specification make clear that a motion
control operation is performed by a motion control device. While RGB proposes a construction
defining motion control operations as being performed “on or by a motion control device,” the
Court finds no support for defining the term this broadly. The Court is unaware of motion control
operations being described in the RGB patents as operations performed on a motion control device
or by something other than a motion control device.
As the Defendants point out, motion control operations are also referred to in the
specification and by RGB during reexamination as being used to move an object in a desired
13 of 64
manner or to perform motion control. (Doc. No. 157, at 6–9, and Ex. B, at 38) (citing ‘236 Patent,
8:26–30); see also ‘236 Patent, 7:20–22 (“The software system designer initially defines a set of
motion control operations that are used to perform motion control.”). However, defining motion
control operations as used to perform motion control—what appears to be the general purpose of
the claimed invention as a whole—while correct, provides little guidance to the jury as to what
motion control operations actually are: the operations performed by the motion control devices.
Further, the construction that the Court gives to “motion control device,” infra, makes clear that
such devices move objects in a desired manner. See infra Part IV.D (construing “motion control
device” as “a device comprising a controller and a mechanical system capable of moving an object
in a desired manner”). Therefore, the Court rejects the Defendants’ construction as it pertains to
this issue.
Regarding the dispute over “abstract” or “hardware independent,” the Court agrees with
the Defendants that the two terms as used synonymously: “The motion control operations are not
specifically related to any particular motion control device hardware configuration, but are
instead abstract operations that all motion control device hardware configurations must perform
in order to function.” ‘236 Patent, 7:22–26. RGB does not appear to dispute that the terms are
used synonymously.5 The Court also agrees with the Defendants that “hardware independent”
provides more guidance to a jury than does “abstract.” Accordingly, the Court will employ the
term that provides the most clarity to a jury.
Lastly, both parties’ proposed constructions include examples of motion control
operations. The Court finds these examples unnecessary and potentially distracting to a jury. At
5. At the Markman hearing, RGB also stated that it was unopposed to the Court’s preliminary construction,
which used “hardware independent” instead of “abstract.” See (Doc. No. 183, at 37–39.)
14 of 64
the Markman hearing, the Court notified the parties that it intended to leave out examples when
defining the terms. The parties did not object to this approach. See (Doc. No. 183, at 37.)
2. Court’s Construction
In light of the claim language and specification, the Court construes “motion control
operations” to mean “hardware independent operations that are performed by a motion
control device.”
C. “Primitive Operations” and “Non-Primitive Operations”6
The RGB Patents disclose two categories of motion control operations: “primitive
operations” and “non-primitive operations.” These two categories (and consequently, the terms’
definitions) are mutually exclusive: a motion control operation is “either a primitive operation . . .
or a non-primitive operation.” ‘236 Patent, claim 1. These two terms also form the basis for the
Defendants’ Motion for Summary Judgment of Invalidity for Indefiniteness. (Doc. No. 158.)
The Defendants claim that the two terms are insolubly ambiguous because it is impossible to
distinguish the boundary between a primitive operation and a non-primitive operation. (Id. at 1.)
Because the construction of these two terms is interrelated, the Court construes the terms together.
The parties agree on the following definition of primitive operations: “motion control
operations, such as GET POSITION and MOVE RELATIVE, necessary for motion control, which
cannot be simulated using a combination of other motion control operations.”7 This language is
taken directly from the specifications of the RGB Patents. ‘058 Patent, 6:56–67; ‘236 Patent,
6. ‘236 Patent, claim 1; ‘058 Patent, claims 1, 3; ‘557 Patent, claims 16, 46; ‘543 Patent, claim 15.
7. In Fanuc, as in this case, the parties agreed that primitive operations are necessary for motion control and
cannot be simulated using a combination of other motion control operations. Fanuc, No. 2:07-CV-418, 2009 U.S.
Dist. LEXIS 127428, at *34–35 (E.D. Tex. Aug. 25, 2009). The disagreement between the parties in that case was
whether examples should be included. Judge Folsom adopted RGB’s definition, which is the same definition that the
parties have agreed to in this case. Id.
15 of 64
7:27–38; ‘557 Patent, 8:17–28; ‘543 Patent, 5:62 to 6:6. RGB contends that the patentee acted as
a lexicographer by defining the term in the specification in this manner. (Doc. No. 151, at 11);
(Doc. No. 183, at 56:10–22). The Defendants, while stating that they agree with this definition,
argue that the term is indefinite because the RGB Patents fail to provide a standard for determining
whether an operation is necessary for motion control and because MOVE RELATIVE can be
simulated using a combination of other motion control operations. (Doc. No. 168, at 1–2.) RGB
explains that “necessary for motion control” means required for any class of motion control
devices. (Doc. No. 171, at 7.) RGB also argues that MOVE RELATIVE cannot be simulated
using a combination of other motion control operations. (Id. at 8–10.)
Despite the fact that the parties have reached an agreed upon definition for primitive
operations, the Court finds it necessary to construe this term. The reasons are threefold. First,
the Court believes that the term carries a more simplified meaning than that proposed by the
parties. Second, while the parties state that they agree on the construction of this term, the
definition they propose results in numerous pages of summary judgment arguments on the
meaning of that definition—demonstrating that the parties are not actually in agreement on the
meaning of this term.
Third, the Court finds that the correct definition of non-primitive
operations relies on determining the correct definition of primitive operations.
For the term non-primitive operations, the parties offer the following:
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
“motion control operations that do not meet the This term is indefinite. To the extent the Court
definition of primitive operations”
construes this term, it should be construed to
mean, “motion control operation(s) that can be
simulated using a combination of primitive
operations.”
RGB argues—as with the definition of primitive operations—that the patentee was acting as a
lexicographer by stating in the specification that “[n]on-primitive operations are motion control
16 of 64
operations that do not meet the definition of a [sic] primitive operations.” (Doc. No. 151, at 11)
(citing ‘236 Patent, 7:35–37.) RGB explains that this definition, when viewed in light of the
parties’ agreed upon definition of primitive operations, includes both (1) motion control operation
that can be simulated using a combination of other motion control operations, and (2) motion
control operations that are not necessary for motion control that cannot be simulated using a
combination of primitive operations. (Id. at 11–12.) In support of this definition, RGB states
that Appendix A to the RGB Patents classifies certain motion control operations in the preferred
embodiment as non-primitive specifically because they are not necessary for motion control. (Id.
at 12, Ex. 10, at 3.2.10.) To illustrate its point, RGB includes the following table.
RGB argues that the Defendants’ definition fails because it excludes from the non-primitive
category those motion control operations that are not necessary for motion control and cannot be
simulated using other motion control operations (reflected in the shaded box in the table). (Id. at
12.) RGB also offers the expert report of David W. Brown—one of the inventors, as well as
RGB’s Chairman of the Board and Chief Technical Officer—to support its definition and clarify
that “necessary for motion control” means required for any class of motion control devices. (Doc.
No. 171, at 7.) At the Markman Hearing, RGB repeatedly referred to Brown’s opinions in order
to support its proposed construction.
17 of 64
The Defendants argue that the term non-primitive operations is indefinite for the same
reasons that the term primitive operations is indefinite: primarily because they believe the RGB
Patents fail to provide a standard for determining whether an operation is necessary for motion
control. (Doc. No. 168, at 5–13.) In the alternative, the Defendants propose that the term be
construed as motion control operations that can be simulated using a combination of primitive
operations. Defendants note that their proposed definition mimics the language of several of the
claims. (Doc. No. 157, at 8 n.5) (“nonprimitive operations that may be simulated using a
combination of primitive operations” (quoting ‘058 Patent, claim 1), “a non-primitive motion
operation that can be performed using a combination of primitive motion operations” (quoting
‘557 Patent, claim 46)).
The Defendants also argue that RGB’s definition of “not necessary for motion control” is
different from that contemplated by the RGB Patents. They contend that, to the extent that
non-primitive operations are considered to be “not necessary for motion control,” they are such
because the system does not need them to reach the same result—the system may simply simulate
them using a combination of primitive operations. (Id. at 8.) The Defendants state that Judge
Folsom so equated “not necessary to perform motion control” and “can be simulated” in Fanuc.
(Id.) (“In addition to GET POSITON [sic] and MOVE RELATIVE, motion control operations
may also take the form of more complicated ‘non-primitive’ operations. Because the Patent
suggests that non-primitive operations can be emulated using a series of primitive operations,
however, not all motion control devices need perform both primitive and non-primitive
operation[s] in order to function.” (quoting Fanuc, No. 2:07-CV-418, 2009 U.S. Dist. LEXIS
127428, at *33 (E.D. Tex. Aug. 25, 2009)). Finally, the Defendants argue that RGB is incorrect
in asserting that Appendix A to the RGB Patents provides any guidance on determining the
18 of 64
meaning of “necessary for motion control” or the meaning of the terms primitive operations and
non-primitive operations. (Id. at 8–9.)
1. Analysis
i. The Claims
Simply by reading the claims of the RGB Patents, it is clear that one skilled in the art would
quickly understand the terms at issue to carry a plain and ordinary meaning: primitive operations
are basic operations that cannot be simulated using a combination of other operations, and
non-primitive operations are more complicated operations that can be simulated using a
combination of other operations.
To begin with, the ‘058 Patent claims unequivocally describe non-primitive operations as
“operations that may be simulated using a combination of primitive operations.” ‘058 Patent,
claims 1, 3. The ‘557 Patent claims do the same: “non-primitive motion operation that can be
performed using a combination of primitive motion operations.” ‘557 Patent, claim 46; see also
id., claim 16 (“a non-primitive motion operation that can be performed using at least one primitive
motion operation”). Therefore, the Court finds it necessary to construe the term as it is defined in
the claims.8
Conversely, primitive operations are described in the ‘557 Patent claims as operations that
“cannot be performed using a combination of primitive or non-primitive motion operations” ‘557
Patent, claim 46; see also id., claim 16 (“where the at least one primitive motion operation cannot
8. E.g., TIP Sys., LLC v. Phillips & Brooks/Gladwin, Inc., 529 F.3d 1364, 1369 (Fed. Cir. 2008) (“The
court noted that the claim expressly states: ‘a telephone handset being a handle with an earpiece at one end and a
mouthpiece at an opposite end.’ Hence, the claim itself contains a precise definition of the term. By first looking to
the claim language, the court recognized that ‘the claims themselves provide substantial guidance as to the meaning of
particular claim terms.’ We find no error by the district court in relying heavily on the claim language to construe the
claim term.”) (internal citations omitted).
19 of 64
be performed using a combination of primitive or non-primitive motion operations”). The ‘236
Patent and the ‘543 Patent claims describe primitive operations in the same fashion. ‘236 Patent,
claim 1 (“a primitive operation the implementation of which is required to operate motion control
devices and cannot be simulated using other motion control operations”); ‘543 Patent, claim 15 (“a
primitive operation the implementation of which is required to control the object and cannot be
simulated using any other motion control operations”). As with non-primitive operations, the
Court finds it necessary to construe primitive operations as it is defined in the claims.9
Based on the inverse meanings that the claims disclose for these two terms, as well as other
language in the claims, one skilled in the art would also understand that the terms are mutually
exclusive: a motion control operation is “either a primitive operation . . . or a non-primitive
operation.” ‘236 Patent, claim 1; see also id. (“a non-primitive operation that does not meet the
definition of a primitive operation”); ‘543 Patent, claim 15 (“each motion control operation
comprises either a primitive operation . . . or a non-primitive operation”).
The Court recognizes that claim 1 of the 236 Patent describes primitive operations as
“required to operate motion control devices” and claims 1 and 3 of the ‘058 Patent describe
primitive operations as “necessary to define the desired motion sequence.” However, the import
of these statements is simply that primitive operations are “necessary” or “required” because they
are basic motion control operations that motion control devices use in combination to accomplish
more complicated, non-primitive operations—they are the basic building blocks of motion control
operations so to speak. See Fanuc, No. 2:07-CV-418, 2009 U.S. Dist. LEXIS 127428, at *33
(E.D. Tex. Aug. 25, 2009) (“[M]otion control operations may also take the form of more
complicated ‘non-primitive’ operations.
Because the Patent suggests that non-primitive
operations can be emulated using a series of primitive operations, however, not all motion control
9. See supra note 8.
20 of 64
devices need perform both primitive and non-primitive operation[s] in order to function. Instead,
the Patent suggests that all motion control devices need only utilize primitive operations.”). In
this sense, the “necessary” and “required” phraseology merely reiterates that primitive operations
are basic operations that cannot be simulated using a combination of other operations. For this
reason, it would be redundant and unnecessary to define primitive operations with a “necessary for
motion control” element.
These statements in the claims also do not go so far as to describe primitive operations as
necessary for motion control in that they are “required for any class of motion control devices” as
RGB advocates. (Doc. No. 171, at 7.) Furthermore, the claims themselves give absolutely no
indication that non-primitive operations are not necessary for motion control such that they are
“bells and whistles” as RGB so strongly urges the Court to define the term. See (Doc. No. 171, at
6.)
Most significantly, the Court notes that RGB’s proposed definition for non-primitive
operations—by which some non-primitive operations actually “cannot be simulated” (Doc. No.
151, at 12)—directly contradicts the claims themselves, which unequivocally describe
non-primitive operations as “operations that may be simulated using a combination of primitive
operations.” ‘058 Patent, claims 1, 3; see also ‘557 Patent, claim 46 (“non-primitive motion
operation that can be performed using a combination of primitive motion operations”). Defining
non-primitive operations as RGB proposes would require the Court to completely disregard, and
effectively rewrite, the claims. See, e.g., Eng’g Corp. v. Bartell Indus., Inc., 299 F.3d 1336, 1349
(Fed. Cir. 2002) (“Allen argues that one of skill in the art would understand that the term
‘perpendicular’ in the claim should be read to mean ‘parallel.’ Allen stretches the law too far. It
is not our function to rewrite claims . . . .”). For this reason alone, RGB’s proposed definition for
non-primitive operations must be rejected.
21 of 64
ii. The Specifications
The specifications of the RGB Patents describe primitive and non-primitive operations in a
manner consistent with the plain and ordinary meaning disclosed in the claims. See Phillips v.
AWH Corp., 415 F.3d 1303, 1321 (Fed. Cir. 2005) (“Properly viewed, the ‘ordinary meaning’ of a
claim term is its meaning to the ordinary artisan after reading the entire patent.”). The two
operations are explained in a mutually exclusive fashion, with the distinction between them being
that primitive operations cannot be simulated using a combination of other operations, and
non-primitive operations can be simulated using a combination of other operations:
Motion control operations may either be primitive operations or non-primitive
operations. Primitive operations are operations that are necessary for motion
control and cannot be simulated using a combination of other motion control
operations. Examples of primitive operations include GET POSITION and
MOVE RELATIVE, which are necessary for motion control and cannot be
emulated using other motion control operations. Non-primitive operations are
motion control operations that do not meet the definition of a [sic] primitive
operations. Examples of non-primitive operations include CONTOUR MOVE,
which may be emulated using a combination of primitive motion control
operations.
‘236 Patent, 7:27–38; ‘058 Patent, 6:56–67; ‘557 Patent, 8:17–28; ‘543 Patent, 5:62 to 6:6; see
also ‘557 Patent, 4:17–22, 4:61–66 (“a non-primitive motion operation that can be performed
using at least one primitive motion operation, where the at least one primitive motion operation
cannot be performed using a combination of primitive or non-primitive motion operations”); id. at
5:37–42 (“a non-primitive motion operation that can be performed using a combination of
primitive motion operations, where primitive motion operations cannot be performed using a
combination of primitive or non-primitive motion operations”).
The specifications do indeed state that “primitive operations are operations that are
necessary for motion control” and that “non-primitive operations are motion control operations
that do not meet the definition of a [sic] primitive operations.” However, these two statements in
22 of 64
the specification are not an instance in which the patentee was acting as his own lexicographer as
RGB argues. “When a patentee acts as his own lexicographer in redefining the meaning of
particular claim terms away from their ordinary meaning, he must clearly express that intent in the
written description.” Merck & Co. v. Teva Pharms. USA, Inc., 395 F.3d 1364, 1370 (Fed. Cir.
2005) (emphasis added) (citing Bell Atl. Network Servs. v. Covad Commc’n Group, Inc., 262 F.3d
1258, 1268 (Fed. Cir. 2001)); see also Phillips v. AWH Corp., 415 F.3d 1303, 1316 (Fed. Cir.
2005) (“[T]he specification may reveal a special definition given to a claim term by the patentee
that differs from the meaning it would otherwise possess.” (emphasis added)). “[T]he statement
in the specification must have sufficient clarity to put one reasonably skilled in the art on notice
that the inventor intended to redefine the claim term.” Merck, 395 F.3d at 1370.
Here, the specification does not clearly express an intent to redefine the terms. This
portion of the specification simply explains how a software system designer will define the set of
motion control operations. ‘236 Patent, 7:19–22 (“The software system designer develops the
software system 22. The software system designer initially defines a set of motion control
operations that are used to perform motion control.”). In doing so, the specification tracks the
claim terms in explaining that primitive operations are those that cannot be simulated using a
combination of other operations, and non-primitive operations are those that can be simulated
using a combination of other operations—it does not redefine these terms away from their plain
and ordinary meaning as disclosed in the claims. Likewise, as made clear by the parties’
protracted arguments over what “necessary for motion control” might mean, the specification does
not “have sufficient clarity to put one reasonably skilled in the art on notice that the inventor
intended to redefine the claim term[s]” to include a necessary/not necessary for motion control
element. Merck & Co., 395 F.3d at 370 (citing Bell Atl. Network Servs., 262 F.3d at 1268. If the
23 of 64
patentee intended for this portion of the specification to serve a definitional function, he should
have clearly expressed his intent to do so and he should have performed this task with such clarity
that it would be clear what was meant by “necessary for motion control.” This is particularly the
case in regards to RGB’s proposition that some non-primitive operations actually “cannot be
simulated.” (Doc. No. 171, at 6.) Since the claim terms state the opposite, the patentee would
have to speak with extreme clarity in order to convey this definition; that task is not performed by
simply stating that “primitive operations are operations that are necessary for motion control” and
that “non-primitive operations are motion control operations that do not meet the definition of a
[sic] primitive operations.”
Furthermore, assuming arguendo that the patentee could be viewed as acting as his own
lexicographer in this instance, the resulting definition would not take the form that RGB proposes.
The specification does not state that “necessary for motion control” means that primitive
operations are “required for any class of motion control devices” (Doc. No. 171, at 7), that
non-primitive operations are “bells and whistles” such that they are not necessary for motion
control (Doc. No. 151, at 12), or that some non-primitive operations actually “cannot be
simulated” (Doc. No. 171, at 6). RGB only arrives at these definitions through much attorney
argument bolstered by the self-serving statements of David W. Brown, one of the inventors and
RGB’s Chairman of the Board. Instead of RGB’s proposed definition, the natural import of
stating that primitive operations are “necessary for motion control” is that these operations cannot
be simulated and thus are the basic building blocks of motion control operations (as with the
“necessary” and “required” phraseology in some of the claims).10 Likewise, the natural import of
the statement in the specification that “non-primitive operations are motion control operations that
10 . See supra Part IV.C.1.ii (examining the claims for the meaning of primitive operations and
non-primitive operations).
24 of 64
do not meet the definition of a primitive operations” is that these operations can be simulated using
a combination of other operations, as exemplified in the sentence immediately following this
statement and as explicitly stated in the claims. See ‘236 Patent, 7:34–38 (“Non-primitive
operations are motion control operations that do not meet the definition of a primitive operations.
Examples of non-primitive operations include CONTOUR MOVE, which may be emulated using
a combination of primitive motion control operations. (emphasis added)); ‘058 Patent, claims 1, 3
(“nonprimitive operations that may be simulated using a combination of primitive operations”).
Finally, to support its position that the term non-primitive operations includes some
operations that cannot be simulated and are not necessary for motion control, RGB refers to
Appendix A to the RGB patents. See (Doc. No. 151, at 12, Ex. 10, at 3.2.10.) Appendix A,
Section 3.2.10, includes a list of extended driver functions (corresponding to non-primitive
operations) that are described as “extra motion control functions that may or may not be
implemented by the motion control hardware.” (Id.) RGB contends that this sentence and list of
functions in Appendix A demonstrates that some driver functions are non-primitive because they
are not necessary for motion control. The Court agrees with the Defendants that this sentence in
Appendix A provides “no such guidance.” (Doc. No. 157, at 8.) Simply stating in an Appendix
that certain functions “may or may not be implemented” is not of sufficient clarity to put one
skilled in the art on notice that the patentee is serving as his own lexicographer. Merck & Co. v.
Teva Pharms. USA, Inc., 395 F.3d 1364, 1370 (Fed. Cir. 2005). Furthermore, whether an
operation “may or may not be implemented by the motion control hardware” is not a distinction
between primitive and non-primitive operations: RGB itself admits that some primitive operations
may not be implemented by all motion control devices. See (Doc. No. 167, at 4–5); (Doc. No.
171, at 6–8).
25 of 64
iii. The Extrinsic Evidence
Both parties seem to suggest that the terms primitive operations and non-primitive are
coined terms. Neither references a dictionary for the definition of “primitive” and compares that
definition to the way the term is used in the RGB Patents. However, reference to both general use
and technical dictionaries confirms the plain and ordinary meaning of the terms at issue as revealed
in the claims and specifications of the RGB Patents. See Phillips v. AWH Corp., 415 F.3d 1303,
1322 (Fed. Cir. 2005) (“Dictionaries or comparable sources are often useful to assist in
understanding the commonly understood meaning of words and have been used both by our court
and the Supreme Court in claim interpretation.”).
The definition of primitive from general use dictionaries is “not derived.”
MERRIAM-WEBSTER’S COLLEGIATE DICTIONARY 986 (11th ed. 2007); see also WEBSTER’S II NEW
RIVERSIDE UNIVERSITY DICTIONARY 934 (1988) (“Serving as the source for derived or inflected
forms.”). Webster’s II New Riverside University Dictionary also gives a similar definition of
“primitive” that it labels as specific to the field of computer science: “A basic or fundamental unit
of machine instruction or translation.” WEBSTER’S II NEW RIVERSIDE UNIVERSITY DICTIONARY
935 (1988). These definitions are congruent with the meaning of the term in the RGB Patents,
which describe primitive operations as basic operations that cannot be simulated using other
operations and non-primitive operations as more complex operations that can be simulated using a
combination of other operations.
Even more enlightening is the definition of primitive listed in a technical dictionary: “In
computer programming, a basic element, such as an operation, which can be combined with others
for more sophisticated operations.”
WILEY ELECTRICAL
AND
ELECTRONICS ENGINEERING
DICTIONARY 603 (Steven M. Kaplan ed., IEEE Press 2004); see also THE IEEE STANDARD
26 of 64
DICTIONARY OF ELECTRICAL AND ELECTRONICS TERMS 817 (Institute of Electrical and Electronics
Engineers, Inc., 6th ed. 1996) (“A basic or fundamental unit, often referring to the lowest level of
machine instruction or the lowest unit of a language.”). This definition is identical to the way the
term is used in the RGB Patents: primitive operations are basic operations that can be combined to
perform more sophisticated, non-primitive operations.
To be clear, the Court is not relying on dictionaries to construe the terms at issue. The
claims of the RGB Patents disclose the meanings of those terms and the specifications reiterate
those meanings. However, the dictionary definition of primitive is the same as that used in the
RGB Patents. In other words, the patentee did not act as his own lexicographer by giving the
terms primitive operations and non-primitive operations novel or coined meanings—the patentee
used the dictionary definitions of these terms. Reference to these dictionaries simply reinforces
the Court’s construction of the terms after reading the claims and specification.
2. Court’s Construction
In light of the claim language, specification, and extrinsic evidence, the Court construes
“primitive operation” to mean “motion control operations that cannot be simulated using a
combination of other motion control operations,” and “non-primitive operations” to mean
“motion control operations that can be simulated using a combination of other motion
control operations.” As will be stated more fully in a report and recommendation that the
undersigned will enter separately, the terms are not indefinite. See Exxon Research & Eng’g Co.
v. United States, 265 F.3d 1371, 1375 (Fed. Cir. 2001) (“If the meaning of the claim is discernible,
even though the task may be formidable and the conclusion may be one over which reasonable
persons will disagree,” the claim is sufficiently clear to avoid invalidity on indefiniteness
grounds.).
27 of 64
D. “Motion Control Device”11
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
“a device comprising a controller and a
“a controller and mechanical system for
mechanical system” or, alternatively, “a device performing motion control”
comprising a controller and a mechanical system
capable of generating movement based on a
control signal”
The parties agree that a motion control device is comprised of a controller and a
mechanical system. Their disagreement is on whether the capabilities or purposes of a motion
control device should be included in the definition, and what those capabilities or purposes are.
RGB would prefer that the term simply be defined as “a device comprising a controller and
a mechanical system.” But RGB proposes the following modifying phrase in case the Court finds
further defining necessary: “capable of generating movement based on a control signal.” (Doc.
No. 151, at 13.)
The Defendants argue that RGB’s definitions are incomplete and overly broad unless they
include a requirement that the device is used “for performing motion control,” with motion control
defined as moving an object in a desired manner. (Doc. No. 157, at 10.) They contend that
without this clarification, the term would cover any mechanical system, including robots and
printers, which RGB stated were not motion control devices during reexamination of the ‘236
Patent. (Doc. No. 157, at 10, Ex. D, at 17.)
In response, RGB does not adequately explain why the Defendants’ definition is incorrect.
They simply describe it as “improperly narrow,” argue that that the Defendants are reading the
prosecution history out of context, and contend that they did not disclaim all robots during
reexamination. (Doc. No. 167, at 5.)
11. ‘236 Patent, claim 1, 10; ‘543 Patent, claims 5–7, 11, 13; ‘557 Patent, claims 16, 20, 24.
28 of 64
1. Analysis
The claim language itself provides guidance on the meaning of “motion control device”:
[E]ach of the motion control devices comprises
a controller capable of generating electrical signals based on at least one
control command of the controller language associated with the motion
control device, and
a mechanical system capable of causing a motion control operation based
on electrical signals generated by the controller, . . .
‘543 Patent, claim 5. This supports the parties’ conclusion that a motion control device is a
device comprising “a controller and a mechanical system.”
Additionally, the specification provides a more detailed description of a motion control
device:
The purpose of a motion control device is to move an object in a desired manner.
The basic components of a motion control device are a controller and a mechanical
system. The mechanical system translates signals generated by the controller into
movement of an object.
‘236 Patent, 1:18–22. The specification confirms that a motion control device is comprised of a
controller and a mechanical system. The specification also explains what a motion control device
is capable of doing—moving an object in a desired manner.
Therefore, from the claim language and specification it becomes clear that a motion control
device is “a device comprising a controller and a mechanical system capable of moving an object
in a desired manner.” At the Markman hearing, the Court presented this definition to the parties as
a preliminary construction. The Defendants suggested that instead of using “capable of” the
Court use “for” in order to convey the intended use of a motion control device. However, the
Court declines this suggestion because it would result in incorrectly defining the device in terms of
its intended use, instead of in terms of what the device actually is. See Paragon Solutions, LLC v.
Timex Corp., 566 F.3d 1075, 1090 (Fed. Cir. 2009) (“‘[A]pparatus claims cover what a device is,
29 of 64
not what a device does.’ If the district court’s construction were correct, then the same apparatus
might infringe when used in one activity, but not infringe when used in another.” (quoting
Hewlett-Packard Co. v. Bausch & Lomb, Inc., 909 F.2d 1464, 1468 (Fed. Cir. 1990))).
2. Court’s Construction
In light of the claim language and specification,12 the Court construes “motion control
device” to mean “a device comprising a controller and a mechanical system capable of
moving an object in a desired manner.”
E. “Application Program”13
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
“a software program designed to handle specific “a software program that directly controls each
tasks”
motor using base incremental steps”
In Fanuc, Judge Folsom found the term “application program” to carry its plain and
ordinary meaning within the RGB Patents, which he held was “a software program designed to
handle specific tasks.” Fanuc, No. 2:07-CV-418, 2009 U.S. Dist. LEXIS 127428, at *12–16
(E.D. Tex. Aug. 25, 2009). RGB urges the Court to follow Judge Folsom’s lead and construe the
term in the same manner. (Doc. No. 151, at 14–15.) It cites technical dictionaries that support
this general definition, as well as an example in the specification that arguably uses the term in a
generic manner. (Id. at 14) (citing ‘236 Patent, 8:30–33) (“any application that uses the system 22
by programming the motion control component 35”). RGB argues that nothing in the claims,
12. While the parties cite the prosecution history to support their own constructions, the Court finds that the
cited portions of the prosecution history are unhelpful in determining the meaning of this term. They certainly do not
contradict the Court’s construction of the term.
13. ‘236 Patent, claims 1, 7, 10; 058 Patent, claims 1–5; ‘557 Patent, claims 5, 16, 20, 35, 46, 50; ‘543
Patent, claims 1, 3, 8, 13.
30 of 64
specifications, or prosecution history suggest that the term carries a different meaning within the
RGB Patents.
The Defendants contend that through distinguishing prior art in the specification, the
patentee limited the term application program to a software program that controls hardware “in
base incremental steps.” (Doc. No. 157, at 12) (citing ‘236 Patent, 3:1–17). They similarly
argue that during reexamination, RGB disavowed the definition that it now seeks when it
distinguished prior art. (Id. at 12–15) (citing numerous statements in the prosecution history.)
1. Analysis
Courts generally give claim terms their ordinary and customary meaning. Phillips v.
AWH Corp., 415 F.3d 1303, 1312–13 (Fed. Cir. 2005). The Court agrees with RGB that as used
in the RGB Patents the term has a plain and ordinary meaning of “a software program designed to
handle specific tasks.” See Fanuc, 2009 U.S. Dist. LEXIS 127428, at *12–16. Application
program is used throughout the claims of the RGB Patents, and a review of the claims does not
indicate that the term carries anything other than this plain and ordinary meaning.14 Likewise, the
14. See, e.g., ‘236 Patent, claim 1 (“an application program comprising a series of component functions,
where the application program defines the steps for operating a motion control device in a desired manner”); 058
Patent, claim 1 (“A system for allowing an application program to communicate with any one of a group of
supported hardware devices . . . the software system comprising at least one application program comprising a set of
component functions defining a desired motion sequence . . . .”); id. at claim 3 (“A system for allowing an application
program to communicate with any one of a group of supported hardware devices, the system comprising: a software
system comprising at least one application program operating on a first workstation, the application program
comprising a set of component functions defining a desired motion sequence . . . .); ‘557 Patent, claim 16 (“A motion
control system, comprising: an application program comprising at least one call to at least one component function .
. . .”); id. at claim 20 (“A motion control system as recited in claim 16, in which the application program further
comprises at least one call to a component function comprising at least one parameter . . . .”); ‘543 Patent, claim 1
(“generating a control command based on an application program and the driver code of the selected software
driver”); id. at claim 3 (“The method of claim 2, wherein the application program comprises a sequence of
component functions, and at least some of the component functions are associated with driver functions.”); id. at claim
13 (“providing an application program comprising a series of component functions”).
31 of 64
term is used throughout the specification, and a review of its use there does not indicate that the
patentee intended to give it a more specific meaning.15
The Defendants fail to show where the patentee clearly redefines the term to a narrower
meaning.16 The portion of the specification cited by the Defendants describes the inability of
prior art printers to be controlled directly from a word processing application program:
The Applicants are also aware of the common programming practice in
which drivers are provided for hardware such as printers or the like; an application
program such as a word processor allows a user to select a driver associated with a
given printer to allow the application program to print on that given printer.
While this approach does isolates [sic] the application programmer from the
complexities of programming to each hardware configuration in existence, this
approach does not provide the application programmer with the ability to control
the hardware in base incremental steps. In the printer example, an application
programmer will not be able to control each stepper motor in the printer using the
provided printer driver; instead, the printer driver will control a number of stepper
motors in the printer in a predetermined sequence as necessary to implement a
group of high level commands.
The software driver model currently used for printers and the like is thus not
applicable to the development of a sequence of control commands for motion
control devices.
‘236 Patent, 3:1–21. What the specification does is distinguish the claimed invention from word
processers that allow a user to print to a given printer through the selection of the driver for that
15. See, e.g., ‘236 Patent, 3:45–49 (The present invention is, in one form, a method of moving an object
comprising the steps of developing a high-level motion control application program comprising a sequence of
component functions that describe a desired object path . . . .”); id. at 4:6–8 (“This arrangement also allows a given
application program to be used without modification for any motion control device having a software driver
associated therewith.”); id. at 51–56 (“Using the system 22, the application program 26 is developed such that it
contains no code that is specific to any one of the exemplary hardware controllers 16. In the normal case, the
application program 26, and thus the user 24 that created the program 26, is completely isolated from the motion
control devices 20.”); id. at 8:25–26 (“The motion control system designer, normally also the user 24, develops the
application program 26.”); id. at 8:30–32 (“The application program 26 is any application that uses the system 22
by programming the motion control component 35.”).
16. In redefining the meaning of particular claim terms away from their ordinary meaning, the intrinsic
evidence must “clearly redefine” a claim term so as to put one reasonably skilled in the art on notice that the patentee
intended to so redefine the claim term. Elekta Instr. S.A. v. O.U.R. Sci. Int’l, 214 F.3d 1302, 1307 (Fed. Cir. 2000);
see also N. Telecom v. Samsung Elecs. Co., 215 F.3d 1281, 1287 (Fed. Cir.2000) (“[C]laim language is given its
ordinary and accustomed meaning except where a different meaning is clearly set forth in the specification or where
the accustomed meaning would deprive the claim of clarity.”).
32 of 64
printer. It does not redefine what is normally meant by “application program” as being a task
oriented software program.
The ability of the application program to do what the prior art could not arises from the
limitations set forth in the claims themselves. For example, claim 1 of the ‘058 patent recites:
A system for allowing an application program to communicate with any one of a
group of supported hardware devices, the system comprising:
a software system operating on at least one workstation, the software
system comprising
at least one application program comprising a set of component
functions defining a desired motion sequence, the desired motion
sequence being comprised of primitive operations that are
necessary to define the desired motion sequence and
non-primitive operations that may be simulated using a
combination of primitive operations,
a core set of core driver functions, where each core driver function is
associated with one of the primitive operations,
an extended set of extended driver functions, where each extended
driver functions is associated with one of the non-primitive
operations,
component code associated with each of the component functions,
where the component code associates at least some of the
component functions with at least some of the driver functions,
a set of software drivers, where each software driver is associated
with one of the hardware devices and comprises driver code for
implementing the driver functions, and
a control command generating module for generating control
commands based on the component functions of the application
program, the component code associated with the component
functions, and the driver code associated with the software
drivers; and
a network communication protocol that allows the control commands to be
communicated from the control command generating module on the at
least one workstation to at least one of the supported hardware devices
over a network.
‘085 Patent, claim 1. The claim limitations specify the application program to comprise a set of
component functions defining a desired motion sequence, including primitive and non-primitive
operations. This structure affords the application program the ability to control motion control
33 of 64
devices in base incremental steps. Distinguishing the invention from the prior art on this basis is
not a redefinition of the term application program within the specification.
The prosecution history remarks echo the same thing. While distinguishing the prior art
during reexamination, RGB argued that the claimed invention, unlike the prior art, enabled an
application program to control devices in base incremental steps:
In contrast, the ‘058 describes an application program comprising a series of
motion control operations, which the system then transforms into control
commands which cause a controller to manipulate motors on a machine. In other
words, in the ‘058 as claimed, the application program can directly control each
motor using base incremental steps, whereas in Sorensen, the application does not
control motors at all, but instead lets the robot control its own motors however it
sees fit in order to accomplish or implement the high level task based commands.
(Doc. No. 157, Ex. A, at 10.) See also (Doc. No. 157, at 12–13) (citing various portions of the
prosecution history). However, in doing so, RGB did not distinguish the prior art on the basis
that it did not employ an application program,17 such that the plain and ordinary meaning of that
term would be disclaimed. Cf. Eolas Techs., Inc. v. Microsoft Corp., 399 F.3d 1325, 1337–38
(Fed. Cir. 2005) (“While the applicants included language about library routines and DLLs in their
response [to the patent examiner], they did not distinguish the ‘906 invention based on these
features, rather such features were merely included in language that outlined Khoyi’s operation.”).
2. Court’s Construction
In light of the claim language, specification, and prosecution history, the Court construes
“application program” to mean “a software program designed to handle specific tasks.”
17. As RGB points out, the portion of the prosecution history that the Defendants primarily cite is followed
by a statement that outlines the five grounds on which the prior art can be distinguished; none of these grounds is the
application program term itself. See (Doc. No. 157, Ex. A, at 11–12.)
34 of 64
F. “Driver Functions”18
Plaintiff’s Proposed Construction
“hardware independent abstract functions that
are separate and distinct from the component
functions”
Defendants’ Proposed Construction
“hardware independent functions that are
separate and distinct from, and located in a
different layer from, the component functions”
The parties dispute whether “driver functions” should be defined as functions that are
“located in a different layer from” component functions and also whether “driver functions”
should be defined as both “hardware independent” and “abstract” functions.
RGB explains that in its preferred embodiment, driver functions exist both on a different
layer from the component functions and on the same layer as component functions. (Doc. No.
151, at 17–18.) The driver functions exist on a software layer that the component functions are
not found on—the drivers. Likewise, the component functions exist on a software layer that the
driver functions are not found on—the application program. However, RGB argues, the driver
functions and component functions also both exist on the same layer—the motion control
component. Id. Because driver functions are found on both the same and different layers from
the component functions, RGB suggests that the Defendants definition would unnecessarily
confuse a jury. For this reason, it requests that the Court not include “and located in a different
layer from” in the definition of driver functions. RGB also requests that the Court define the term
using the phrase “hardware independent abstract functions” because that is the how it described
the term during reexamination. (Doc. No. 151, at 19, Ex. 25, at 8.)
The Defendants point out that during reexamination, RGB described driver functions as
being located on separate and distinct layer from the component functions. Defendants argue that
RGB should not now be allowed to define the term otherwise. (Doc. No. 157, at 17–19.) The
Defendants also contend that nothing in the patents suggest that the driver functions exist on the
18. ‘236 Patent, claims 1–6, 10; ‘058 Patent, claims 1, 3, 4; ‘557 Patent, claims 16–19, 29, 46–49; ‘543
Patent, claims 2–4, 6–8, 14–16.
35 of 64
motion control component and thus on the same layer as component functions. (Id. at 19.)
Regarding “hardware independent abstract functions,” the Defendants refer the Court to their
arguments on this point regarding the term “motion control operations.” See (Doc. No. 157, at 7,
24.)
1. Analysis
By reading the claim terms themselves, one skilled in the art would understand driver
functions to be functions that are separate and distinct from both component functions and motion
control operations, but that are associated with both component functions and motion control
operations:
A system for generating a sequence of control commands for controlling a selected
motion control device selected from a group of supported motion control devices,
comprising:
a set of motion control operations, where each motion control operation is
either a primitive operation the implementation of which is required to
operate motion control devices and cannot be simulated using other
motion control operations or a non-primitive operation that does not meet
the definition of a primitive operation;
a core set of core driver functions, where each core driver function is
associated with one of the primitive operations;
an extended set of extended driver functions, where each extended driver
function is associated with one of the non-primitive operations;
a set of component functions;
component code associated with each of the component functions, where
the component code associates at least some of the component functions
with at least some of the driver functions . . . .
‘236 Patent, claim 1. The specification confirms what is evident from the claims themselves.
See id. at 7:43–46 (describing driver functions as separate and distinct from, but associated with,
motion control operations); id. at 7:56–59 (describing driver functions as separate and distinct
from, but associated with, component functions). The specification also explains that driver
functions are like motion control operations, construed supra, in that they are abstract or hardware
independent. See id. at 7:22–26 (“The motion control operations are not specifically related to
36 of 64
any particular motion control device hardware configuration, but are instead abstract operations . .
. .”); id. at 7:46–51 (“As with motion control operations, driver functions are not related to a
specific hardware configuration . . . .”). The parties are therefore correct on the portions of their
constructions in which they agree.
As for whether “abstract” should be included within the definition, the Court finds that the
same reasoning as stated above for “motion control operations” applies here. The two terms are
used synonymously within the specification. Because “hardware independent” provides more
guidance to a jury than does “abstract,” the Court will employ hardware independent only.
The primary issue though is whether driver functions should be defined as functions that
are located in a different layer from the component functions. To begin with, there is no
indication in the claim terms themselves that driver functions exist only on a separate software
layer from the component functions. Moving to the specification, the parties agree that driver
functions are described as existing on different layers within RGB’s preferred embodiment. But
that alone is insufficient to allow the Court to limit the term in the manner that the Defendants
request.
Comark Commc’ns, Inc. v. Harris Corp., 156 F.3d 1182, 1187 (Fed. Cir. 1998)
(“particular embodiments and examples appearing in the specification will not generally be read
into the claims” (quoting Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed.
Cir. 1988)) (internal quotation marks omitted)).
The Defendants propose that the SPI and API interfaces (comprising driver functions and
component functions, respectively) are separate layers as shown by the specification, and thus the
driver functions and component functions are described in the specification as existing on separate
layers. (Doc. No. 157, at 17–18) (citing ‘543 Patent, 6:8–24). The Defendants go on to state that
RGB clarified during reexamination that the API and SPI are separate and distinct layers. (id. at
37 of 64
18 and Ex. I.) But the portion of the specification that the Defendants cite does not state or imply
that the SPI and API are separate software layers.
The inference to be drawn from the
specification is, instead, that the SPI and API are in fact “interfaces” that allow for communication
between the application program, motion control component, and drivers. This understanding of
the interfaces is reflected in the portions of the prosecution history that the Defendants cite. See
(id. Ex. I, at 12–13.) There, RGB identified the API and SPI as two interfaces and showed them
as such in the diagram reproduced here.
(Id. at 12.) As shown in the diagram, the API and SPI interfaces sit between layers in the software
system; the interfaces are not themselves “layers” despite a misnomer reference to “layers” in the
prosecution history. Furthermore, as stated above, even if RGB’s preferred embodiment is
correctly described as having separate API and SPI interfaces which are to be understood as
“layers,” that does not mean that an interface or layer limitation should be read into the claims
when one otherwise cannot be found there. See Comark Commc’ns, Inc., 156 F.3d at 1187.
Finally, the undersigned finds compelling RGB’s argument and supporting evidence that
in the preferred embodiment the driver functions also exist on the same software layer—namely
the motion control component. See (Doc. No. 151, at 17–18) (citing ‘236 Patent, 7:54–56, 9:29–
33, 10:40–43, and Figure 2); see also (Defendants’ Markman Brief, Doc. No. 157, at 15–16)
(describing the component code, which resides in the motion control component, as converting
38 of 64
component functions into driver functions). If this is the case, as it appears to be, the driver
functions exist both on a different layer from the component functions and on the same layer as
component functions. Telling a jury that driver functions are located on a different layer from the
component functions unnecessarily runs the risk of confusing the jury.
2. Court’s Construction
In light of the claim language, specification, and prosecution history, the Court construes
“driver functions” to mean “hardware independent functions that are separate and distinct
from the component functions.”
G. “Core Driver Function”19 and “Extended Driver Function”20
Terms
“core
driver
function”
“extended
driver
function”
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
“a driver function associated with one or “a driver function that identifies one of the
more primitive operations”
primitive motion control operations”
“a driver function associated with one or “a driver function that identifies one of the
more non-primitive operations”
non-primitive motion control operations”
The parties briefed and argued these terms together because their disputes apply equally to
both terms. The issues presented by the parties are whether the driver functions are “associated
with” or “identify” motion control operations and whether they do so on a one-to-one or
one-to-many basis.
RGB states that the patents clearly teach that the driver functions “associate with” motion
control operations. (Doc. No. 151, at 20) (citing 236 Patent, 7:44–46, 8:10–14, 48:22–27). As to
the second issue, RGB argues that the use of “a” and “one” in the patents should be interpreted as
19. ‘236 Patent, claims 1–2, 4–6; ‘058 Patent, claims 1, 3; ‘557 Patent, claims 16–19, 46–49; ‘543 Patent,
claim 15.
20. ‘236 Patent, claims 1, 3–6; ‘058 Patent, claims 1, 3; ‘557 Patent, claims 16, 18, 19, 46, 48, 49; ‘543
Patent, claim 15.
39 of 64
meaning “one or more.” (Doc. No. 151, at 20–21) (citing Accent Packaging, Inc. v. Leggett &
Platt, Inc., 707 F.3d 1318, 1326 (Fed. Cir. 2013)).
The Defendants respond that “associates with” is unclear and insufficiently describes the
relationship between driver functions and motion control operations. (Doc. No. 157, at 20.)
They contend that the term “identifies” more clearly and accurately describes the relationship, and
they point to instances in the prosecution history in which RGB used “identifies” to describe the
relationship.
(Id. at 20–21, Ex. A, at 3, 8, Ex. P, at 2, Ex. Q, at 4.)
For the second
issue—whether “a” and “one” mean one or more in the patents—the Defendants disagree with
RGB’s characterization of the case law. (Id. at 21–22) (citing Harari v. Lee, 656 F.3d 1331,
1341–42 (Fed. Cir. 2011), Insituform Techs. v. Cat Contr., 99 F.3d 1098, 1105–06 (Fed. Cir.
1996), and Tulip Computer Int’l B.V. v. Dell Computer Corp., 236 F. Supp. 2d 364, 397–99 (D.
Del. 2002)).
1. Analysis
The claim terms unambiguously state that “each core driver function is associated with one
of the primitive operations” and “each extended driver function is associated with one of the
non-primitive operations.” ‘236 Patent, claim 1; ‘058 Patent, claims 1, 3; ‘543 Patent, claim 15.
The Defendants request that the Court employ “that identifies” instead of the words used in the
claim. Likewise, RGB requests that the Court employ “one or more” instead of the words used in
the claim. The Court finds that the meaning of the claim terms is clear and that there is no basis
for employing the modifications that the parties request.
Regarding the Defendants’ request, there is no support in the claims for defining a driver
function as something that performs the operation or action of identifying a motion control
operation. Instead, the claims specifically state that a driver function is already associated with
40 of 64
(i.e., paired or matched with) a motion control operation. See ‘236 Patent, claim 1; ‘058 Patent,
claims 1, 3; ‘543 Patent, claim 15, ‘557 Patent, claim 16. Like the claims, the specification
clearly states that a driver function is “associated with” a motion control operation. ‘236 Patent,
7:44–46. The specification also suggests that when designing the system, a software designer
predetermines which driver function is associated with which motion control operation:
The software system designer develops the software system 22. The
software system designer initially defines a set of motion control operations that are
used to perform motion control. . . .
Given the set of motion control operations as defined above, the software
system designer next defines a service provider interface (SPI) comprising a
number of driver functions. Driver functions may be either core driver functions
or extended driver functions. Core driver functions are associated with primitive
operations, while extended driver functions are associated with non-primitive
operations.
Id. at 7:19–46. The portions of the prosecution history that the Defendants cite also do not
support defining the term as the Defendants request. While in one instance RGB describes a core
driver function as identifying a motion control operation, RGB is using the terms “associate” and
“identify” interchangeably during this isolated portion of the prosecution history. See (Doc. No.
157, Ex. A, at 7–8.) Additionally, in concluding the portion of prosecution history that the
Defendants cite, RGB recaps that “one of skill in the art would necessarily conclude that . . . driver
functions are hardware independent abstract functions that are associated with primitive or
non-primitive motion control operations . . . .” (Id. at 8.) Therefore, the undersigned finds no
support for diverting from the plain language used in the claims as the Defendants request.
In the same manner, RGB is unable to garner support for its requested definition from the
claim language, specification, or prosecution history. There is no suggestion in the claims that
individual driver functions are associated with more than one motion control operation as RGB
would have the Court so define the term. In fact, the claims suggest the opposite by explicitly
41 of 64
stating that “each” driver function “is associated with one of the” motion control operations. ‘236
Patent, claim 1 (“each core driver function is associated with one of the primitive operations . . .
each extended driver function is associated with one of the non-primitive operations”) (emphasis
added); ‘058 Patent, claims 1, 3 (same); ‘543 Patent, claim 15 (same); see, e.g., WMS Gaming Inc.
v. Int’l Game Tech., 184 F.3d 1339, 1350 (Fed. Cir. 1999) (“The plain meaning of ‘selecting one
of said . . . numbers’ is selecting a single number, not a combination of numbers.” (citing
Insituform Techs., Inc. v. Cat Contracting, Inc., 99 F.3d 1098, 1105 (Fed. Cir. 1996))). The ‘557
Patent makes it even clearer that the relationship is one-to-one by specifying that a core driver
function “is associated with a single one of the primitive motion operations.” ‘557 Patent, claim
46 (emphasis added). A further reading of the claims as a whole also supports the one-to-one
definition: in regards to other terms, the patentee specifically claims a one-to-many relationship by
using the language “at least one” and “plurality.” See, e.g., ‘557 Patent, claim 16 (“a plurality of
unique controller languages are associated with the plurality of motion control devices”)
(emphasis added); id. (“each software driver is associated with at least one of the plurality of
controller languages”) (emphasis added); id. (“the driver code of at least one software driver
associates at least one driver function with at least one control command of the at least one
controller language associated with at least one of the software drivers, and at least one selected
software driver is associated with at least one selected motion control device . . . the component
code associates at least one of the component functions with at least one of the driver functions”)
(emphasis added); see also ‘557 Patent, claims 17–19, 47, 48 (using the same language). That the
patentee clearly specified a one-to-many relationship in regards to other terms reinforces the
understanding that only a one-to-one relationship was claimed in regards to the “driver function”
term. See Harari v. Lee, 656 F.3d 1331, 1341 (Fed. Cir. 2011) (noting that a patentee’s use of
42 of 64
both singular and plural language in claims suggested that singular language carried only a
singular meaning). If RGB had intended to claim a one-to-many relationship between driver
functions and motion control operations, it would have used the phrase “at least one.”
The Court also briefly notes that it has not unearthed—and RGB has not directed the
Court’s attention to—anything in the specification or prosecution history that would indicate that
the association between driver functions and motion control operations is one-to-many.
Despite the clarity of the claim language and absence of a contrary indication in the
specification or prosecution history, RGB argues that the Court should adopt its definition because
Federal Circuit precedent establishes (1) that “a” means “one or more” and, (2) that “one” also
means “one or more.” See (Doc. No. 151, at 20–21) (citing Accent Packaging, Inc. v. Leggett &
Platt, Inc., 707 F.3d 1318, 1326 (Fed. Cir. 2013)). Regarding the former, RGB refers to the
following principle: “an indefinite article ‘a’ or ‘an’ in patent parlance carries the meaning of ‘one
or more’ in open-ended claims containing the transitional phrase ‘comprising.’”
Baldwin
Graphic Sys., Inc. v. Siebert, Inc., 512 F.3d 1338, 1342 (Fed. Cir. 2008) (quoting KCJ Corp. v.
Kinetic Concepts, Inc., 223 F.3d 1351, 1356 (Fed. Cir. 2000)) (internal quotation marks omitted).
However, this principle does not command the definition that RGB seeks.
First, three of the RGB patents do not use “a” or “an” at all; they instead clearly state that
“each core driver function is associated with one of the primitive operations” and “each extended
driver function is associated with one of the non-primitive operations.” ‘236 Patent, claim 1; ‘058
Patent, claims 1, 3; ‘543 Patent, claim 15. The fourth RGB Patent, the ‘557 Patent, uses different
language than the other three and does employ the indefinite article “a.” ‘557 Patent, claim 16
(“at least one driver function is an extended driver function that is associated with a non-primitive
motion operation . . . at least one driver function is a core driver function that is associated with a
43 of 64
primitive motion operation”). The principle cited above, though, “does not set a hard and fast rule
that ‘a’ always means one or more than one. Instead, [courts] read the limitation in light of the
claim and specification to discern its meaning.” Harari v. Lee, 656 F.3d 1331, 1341 (Fed. Cir.
2011) (citing Insituform Techs., Inc. v. Cat Contracting, Inc., 99 F.3d 1098, 1105–06 (Fed. Cir.
1996)). “When the claim language and specification indicate that ‘a’ means one and only one, it
is appropriate to construe it as such even in the context of an open-ended ‘comprising’ claim.” Id.
As described above, when the “driver function” limitation is read in light of the claims as a whole
and the specification, the conclusion to be drawn is that (despite the use of “a”) there is only a
one-to-one association between driver functions and motion control operations. See, e.g., id.
(reaching a similar conclusion based on the claim language and specification); AbTox Inc. v.
Exitron Corp., 122 F.3d 1019, 1024 (Fed. Cir. 1997) (same); Insituform Techs., 99 F.3d at 1105
(same). In the ‘557 Patent in particular, the patentee specifically claimed—within the same
claim—one-to-many associations in regards to other terms, but did not do so with regard to the
“driver function” terms. See generally ‘557 Patent, claim 16. The ‘557 Patent also states, within
claim 46, that a core driver function “is associated with a single one of the primitive motion
operations.” ‘557 Patent, claim 46 (emphasis added).
Second, Accent Packaging does not hold that “one” means “one or more” as RGB
suggests. See Accent Packaging, Inc. v. Leggett & Platt, Inc., 707 F.3d 1318 (Fed. Cir. 2013).
Instead, the result in that case was the product of the Federal Circuit reading the claims in light of
the specification, which included a preferred embodiment demonstrating a pairing of one-to-many.
Id. at 1325–26. The Federal Circuit noted that the use of “one” in the claims suggested a
one-to-one pairing, but based on the preferred embodiment it did not employ such a definition
because “a claim interpretation that excludes a preferred embodiment from the scope of the claim
44 of 64
is rarely, if ever, correct.”
Id. at 1326 (quoting On-Line Techs., Inc. v. Bodenseewerk
Perkin-Elmer GmbH, 386 F.3d 1133, 1138 (Fed. Cir. 2004)) (internal quotation marks omitted).
In the instant case, the claim language describes a one-to-one association, and unlike in Accent
Packaging, the preferred embodiment does not demonstrate a one-to-many relationship that must
be accounted for when defining the term.21
2. Court’s Construction
In light of the claim language and specification, the Court construes “core driver
function” to mean “a driver function associated with one of the primitive motion control
operations” and “extended driver function” to mean “a driver function associated with one of
the non-primitive motion control operations.”
H. “Network”22
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
“interconnected computing devices”
“group of computers and associated devices that
are connected by communications facilities”
In their briefing on this term, the parties simply offered dueling dictionary definitions.
The Court, after reviewing the claims and specification, finds that the term “network” carries a
plain and ordinary meaning of “a communications and data exchange system created by
connecting two or more computers.”
At the Markman hearing, the Court presented this
21. At the Markman hearing, the Court asked counsel for RGB how a driver function could be paired with
multiple motion control operations. (Doc. No. 183, at 159.) RGB did not argue that the preferred embodiment
associated a driver function with multiple motion control operations; it instead explained how the Defendants might
argue that their software did not infringe the RGB Patents because it did associate a driver function with different
motion control operations at different points in time through the use of “tags.” (Id. at 159–164.) After reading the
claims and specification, the Court is unaware of how the invention could be practiced using a one-to-many
association between driver functions and motion control operations. Additionally, counsel for RGB admitted at the
Markman hearing that “at any given time, [a driver] function is only going to be associated with one motion control
operation.” (Id. at 160:9–12.)
22. ‘058 Patent, claims 1–4; ‘543 Patent, claim 12.
45 of 64
construction to the parties and the parties agreed to the Court’s construction. (Doc. No. 183, at
169:10–15.)
Accordingly, the parties and Court being in agreement, the Court construes
“network” to mean “a communications and data exchange system created by connecting two
or more computers.”
V. Construction of Disputed Means-Plus-Function Terms
The asserted patents also contain means-plus-function limitations that require construction.
Means-plus-function limitations are governed by 35 U.S.C. § 112, ¶ 6, which provides:
An element in a claim for a combination may be expressed as a means or step for
performing a specified function without the recital of structure . . . in support
thereof, and such claim shall be construed to cover the corresponding structure . . .
described in the specification and equivalents thereof.
35 U.S.C. § 112, ¶ 6 (2006); see Chi. Bd. Options Exch., Inc. v. Int’l Sec. Exch., LLC, 677 F.3d
1361, 1367 (Fed. Cir. 2012).
Construing a means-plus-function limitation involves two steps. The court must first
identify the claimed function, and then look to the specification and identify the corresponding
structure that performs that function. Chi. Bd. Options Exch., Inc., 677 F.3d at 1367. Under the
second step, a “structure disclosed in the specification is ‘corresponding’ structure only if the
specification or prosecution history clearly links or associates that structure to the function recited
in the claim.” Med. Instrumentation & Diagnostics Corp. v. Elekta AB, 344 F.3d 1205, 1210
(Fed. Cir. 2003) (quoting B. Braun Med., Inc. v. Abbott Labs., 124 F.3d 1419, 1424 (Fed. Cir.
1997)) (internal quotation marks omitted). “While corresponding structure need not include all
things necessary to enable the claimed invention to work, it must include all structure that actually
performs the recited function.” Default Proof Credit Card Sys., Inc. v. Home Depot U.S.A., Inc.,
412 F.3d 1291, 1298 (Fed. Cir. 2005).
46 of 64
“[I]n a means-plus-function claim ‘in which the disclosed structure is a computer, or
microprocessor, programmed to carry out an algorithm, the disclosed structure is not the general
purpose computer, but rather the special purpose computer programmed to perform the disclosed
algorithm.’” Aristocrat Techs. Austl. Prop. Ltd. v. Int’l Game Tech., 521 F.3d 1328, 1333 (Fed.
Cir. 2008) (quoting WMS Gaming Inc., v. Int’l Game Tech., 184 F.3d 1339, 1349 (Fed. Cir.
1999)); see also Harris Corp. v. Ericsson Inc., 417 F.3d 1241, 1253 (Fed. Cir. 2005) (“A
computer-implemented means-plus-function term is limited to the corresponding structure
disclosed in the specification and equivalents thereof, and the corresponding structure is the
algorithm.”).
“The usage ‘algorithm’ in computer systems has broad meaning, for it encompasses ‘in
essence a series of instructions for the computer to follow,’ whether in mathematical formula, or a
word description of the procedure to be implemented by a suitably programmed computer.”
Typhoon Touch Techs., Inc. v. Dell, Inc., 659 F.3d 1376, 1384 (Fed. Cir. 2011) (quoting In re
Waldbaum, 457 F.2d 997, 998 (C.C.P.A. 1972)). Courts have defined an “algorithm” as a “fixed
step-by-step procedure for accomplishing a given result; usually a simplified procedure for solving
a complex problem, also a full statement of a finite number of steps.” Id. at 1385 (quoting In re
Freeman, 573 F.2d 1237, 1246 (C.C.P.A. 1978)) (internal quotation marks omitted). “Precedent
and practice permit a patentee to express that procedural algorithm ‘in any understandable terms
including as a mathematical formula, in prose, or as a flow chart, or in any other manner that
provides sufficient structure.’” Id. (quoting Finisar Corp. v. DirecTV Group, Inc. 523 F.3d 1323,
1340 (Fed. Cir. 2008)). A patentee is “not required to produce a listing of source code or a highly
detailed description of the algorithm to be used to achieve the claimed functions in order to satisfy
35 U.S.C. § 112, paragraph 6.” Aristocrat, 521 F.3d at 1338. He or she is required, however, to
47 of 64
at least disclose the algorithm that transforms the general purpose microprocessor to a special
purpose computer programmed to perform the disclosed algorithm. Id.
In the instant case, the parties have agreed that the following five terms from the ‘236
Patent are means-plus-function limitations. The parties also agree on the function of these
limitations. After review of the ‘236 Patent, and in light of the agreement of the parties, the Court
finds that the following five terms are means-plus-function limitations with the functions
identified by the parties. The following discussion therefore only addresses the corresponding
structures for these means-plus-function limitations.
A. “Means for Determining a Driver Unit System Employed by the Software Drivers”23
Function: “determining a driver unit system employed by the software drivers”
Plaintiff’s Proposed Structure
Defendants’ Proposed Structure
“CDriverMgr object within motion component
“software code that determines the driver unit
system by querying the driver, and equivalents” 34, as identified in the ‘236 Patent at col. 11,
lines 15–19 and col. 11, line 58–col. 13, line 6,
and equivalents thereof”
RGB explains that in the preferred embodiments, the application program uses a unit
system denominated as the Part Coordinate System (“PCS”) and the driver uses a unit system
denominated as the Machine Coordinate System (“MCS”). (Doc. No. 151, at 25) (citing ‘236
Patent, at 11:19–21, 12:49–51). RGB then states that the preferred embodiments teach the
algorithm “querying the driver” for determining the driver unit system. To support this assertion,
RGB cites to Appendix B to the RGB Patents, which lists a software function of
“(*pMotion)->GetUnits( ).” (Id. at 25, Ex. 12 § 4.2.8.) RGB also argues that the Defendants “do
not even attempt to discern an algorithm,” and that the Defendants proposed construction will
simply confuse the jury.
23. ‘236 Patent, claim 7.
48 of 64
The Defendants point the Court to the portions of the specification that describe the
determination of the MCS and conversion of units between the PCS and MCS. (Doc. No. 157, at
25–26) (citing ‘236 Patent, at 11:15–19, 12:19–21, 12:54–56).
The Defendants state that
“CDriverMgr”—a software module listed in the specification—is the only structure identified in
the specification that performs the function of determining a driver unit system employed by the
software drivers. (Id.) The Defendants also argue that RGB’s construction encompasses any
software that performs the function of determining the driver unit system by querying the driver,
and equivalents.
1. Analysis
The corresponding structure for a mean-plus-function limitation is to be found in a patent’s
specification. 35 U.S.C. § 112, ¶ 6 (2006). The Defendants correctly cite to the portion of the
specification that describes the function of determining a driver unit system employed by the
software drivers and the means for performing that function. See ‘236 Patent, 11:15–19, 11:58 to
13:6. The Court also finds that Figures 6 and 7, as referenced in this portion of the specification,
depict the structure that performs the function. See ‘236 Patent, 12:26–28, 12:43–48, Figs. 6–7.
RGB fails, unlike the Defendants, to indicate where its alleged corresponding algorithm structure
is clearly linked in the specification. See Med. Instrumentation & Diagnostics Corp. v. Elekta
AB, 344 F.3d 1205, 1210 (Fed. Cir. 2003) (“[S]tructure disclosed in the specification is
‘corresponding’ structure only if the specification or prosecution history clearly links or associates
that structure to the function recited in the claim.” (quoting B. Braun Med., Inc. v. Abbott Labs.,
124 F.3d 1419, 1424 (Fed. Cir. 1997)) (internal quotation marks omitted)). Although RGB
makes a number of random cites to the specification and generally summarizes the disclosure
49 of 64
there, nowhere does it specifically cite where there is a clear linkage to the function. See
generally (Doc. No. 151, at 24–25.)
The Court finds that the portions of the specification identified above clearly list the
“CDriverMgr” as the special purpose software module that carries out the function of determining
a driver unit system. See Aristocrat Techs. Austl. Prop. Ltd. v. Int’l Game Tech., 521 F.3d 1328,
1333 (Fed. Cir. 2008) (“[I]n a means-plus-function claim ‘in which the disclosed structure is a
computer, or microprocessor, programmed to carry out an algorithm, the disclosed structure is not
the general purpose computer, but rather the special purpose computer programmed to perform the
disclosed algorithm.’” (quoting WMS Gaming Inc., v. Int’l Game Tech., 184 F.3d 1339, 1349
(Fed. Cir. 1999))). RGB does not argue that the “CDriverMgr” is not the specialized software
that performs the specified function. In fact, at the Markman hearing, RGB conceded that
“CDriverMgr” was the correct structure. (Doc. No. 183, at 173:20–22) (“So, your Honor, my
thing is I think in general what they have identified is the correct structure in terms of
CUnitMapper or CDriverMgr.”). Despite this admission, RGB asks that the Court generalize the
structure to “software code” that performs the single step of “querying the driver.” The Court
finds no support for this approach. The correct approach is to refer to the CDriverMgr and the
portions of the specification that disclose its operation.24
24. E.g., Harris Corp. v. Ericsson Inc., 417 F.3d 1241, 1254 (Fed. Cir. 2005) (“Specifically, the patent
discloses, as corresponding structure, a processor 37, ‘advantageously comprised of a pair of processors - a support
processor (SUPP) [37A] and a fast array processor (FAP) [37B,]’ shown in Figure 4 and described at col. 11, l. 37 -col.
12, l. 32, which is programmed to carry out the disclosed ‘data recovery algorithm’ illustrated in Figures 8A, 8B, and
9 and described at col. 7, l. 18 -col. 8, l. 38; col. 13, l. 45 -col. 14, l. 20; and col. 15, l. 2 -col. 16, l. 11.”); Lockheed
Martin Corp. v. Space Systems/Loral, Inc., 324 F.3d 1308, 1315 (Fed. Cir. 2003) (“The structure corresponding to the
means recited in limitation [b] is the sine generator (46) and wheel electronics (48) noted in Figure 4 above. . . . The
structure corresponding to the means recited in limitation [c] is the tachometer (52) and difference amplifier (54). . . .
The structure corresponding to the means recited in limitation [d] is the ‘earth horizon’ or ‘roll’ sensor (56) discussed
above.”); Commonwealth Scientific and Indus. Research Org. v. Lenovo (U.S.), Inc., No. 6:09–CV–399, 2012 WL
170972, at *8 (E.D. Tex. Jan. 20, 2012) (Davis, C.J.) (“[T]he Court finds that the structure is the synchronising
calculator and detector in Figure 6 and the synchronising calculator and detector block 65 in Figure 8.”).
50 of 64
Finally, in its briefs and at the Markman hearing, RGB argued that the CDriverMgr and the
corresponding cites to the specification do not offer sufficient definition of an algorithm to allow a
jury to perform an infringement analysis. That may well be, but it does not mean that the Court’s
identification of a clearly linked structure is wrong. While RGB’s argument may highlight proof
or validity problems, those issues are not before the Court.
2. Court’s Construction
The Court finds that “means for determining a driver unit system employed by the
software drivers” is a means-plus-function limitation with the function of “determining a driver
unit system employed by the software drivers” and the structure of “CDriverMgr object within
motion component 34, as identified in the ‘236 Patent at 11:15–19, 11:58 to 13:6, Figs. 6–7,
and equivalents thereof.”
B. “Means for Converting an Application Unit System Employed by the Application Program
into the Driver Unit System”25
Function: “converting an application unit system employed by the application program into the
driver unit system”
Plaintiff’s Proposed Structure
Defendants’ Proposed Structure
“CUnitMapper object within motion component
“software code that converts measurements from
34, as identified in the ‘236 Patent at col. 11, line
one unit system to another by applying a
15–col. 13, line 6, and equivalents thereof”
conversion factor, and equivalents”
The parties agree that the “CUnitMapper” software module described in the specification
is the structure that performs the stated function of converting units between the PCS and MCS.
See (Doc. No. 151, at 25–26); (Doc. No. 157, at 26); (Doc. No. 183, at 173:20–22). The parties
also cite to similar portions of the specification in describing how the CUnitMapper carries out this
function. See (Doc. No. 151, at 26) (citing ‘236 Patent, 11:19–22, 12:19–21) (Doc. No. 157, at
25. ‘236 Patent, claim 7.
51 of 64
32–33) (citing ‘236 Patent, 11:19–21, 12:19–21, 12:54–56). However, as with the last term, RGB
requests a generalized description of the structure, and the Defendants request a description that
names the specific software module and the portions of the specification that disclose its operation.
1. Analysis
The Court agrees with the parties that CUnitMapper is the specialized software module
identified in the specification that carries out the function of converting an application unit system
into the driver unit system. The Court finds that both parties correctly cite portions of the
specification that describe the means by which the CUnitMapper performs this function.
Specifically, the Court finds that the CUnitMapper and its operation are depicted in the ‘236 Patent
at 11:17–22, 12:19–21, 12:36–38, 12:43–58, and Figs 6–7. As with the last term, RGB asks the
Court to generalize the structure to “software code that converts measurements from one unit
system to another by applying a conversion factor, and equivalents.” For the reasons stated above
in relation to the last term, the Court will not employ RGB’s requested approach.26
2. Court’s Construction
The Court finds that “means for converting an application unit system employed by
the application program into the driver unit system” is a means-plus-function limitation with
the function of “converting an application unit system employed by the application program into
the driver unit system,” and the structure of “CUnitMapper object within motion component
34, as identified in the ‘236 Patent at 11:17–22, 12:19–21, 12:36–38, 12:43–58, Figs 6–7, and
equivalents thereof.”
26. See supra note 24 and accompanying text. The Court also notes that RGB’s proposed construction is
incorrect because it essentially restates the function. See Aristocrat Techs. Austl. PTY Ltd. v. Int’l Game Tech., 521
F.3d 1328, 1334 (Fed. Cir. 2008) (“The equation thus does not disclose the structure of the claimed device, but is only
another way of describing the claimed function.”).
52 of 64
C. “Means for Generating Command Data Strings for Controlling the Selected Motion Control
Device Based on the Command Format Template and the Application Program”27
Function: “generating command data strings for controlling the selected motion control device
based on the command format template and the application program”
Plaintiff’s Proposed Structure
Defendants’ Proposed Structure
“software code that utilizes the set of commands “language driver using a database, the key fields
of which are an index field a command format
making up the motion control command
field and a response format field, as identified in
language and builds command data strings
according to a command format template based the ‘236 Patent at col. 34, lines 28–40 and
upon the motion control operation(s) requested equivalents thereof”
by the application program, and equivalents”
RGB explains that the “language driver[s] 44,” described in the ‘236 Patent, at 35:17–22,
construct command data string containing ASCII characters using the command format template.
(Doc. No. 151, at 28) (“[T]he language driver 44 will construct a command data string . . . .” (citing
‘236 Patent, 35:17–22)). RGB also describes steps by which the language drivers 44 perform this
function. (Id.) RGB then simply concludes that the structure is “software code that utilizes the
set of commands making up the motion control command language and builds command data
strings according to a command format template based upon the motion control operation(s)
requested by the application program, and equivalents.” (Id.)
The Defendants also identify the language drivers 44 as performing the function of
generating command data strings. (Doc. No. 157, at 28) (citing ‘236 Patent, 34:28–38). The
Defendants argue that RGB’s construction is overly broad and encompasses any software code
that performs the stated function.
1. Analysis
The Court agrees with the parties that language drivers 44 are the software modules
identified in the specification that carry out the function of generating command data strings for
27. ‘236 Patent, claim 10.
53 of 64
controlling the selected motion control device based on the command format template and the
application program. See ‘236 Patent, 35:17–22 (“Using the command format template, the
language driver 44 will construct a command data string . . . .”). The Court rejects RGB’s
proposed structure as it simply restates the function. See Aristocrat Techs. Austl. PTY Ltd. v.
Int’l Game Tech., 521 F.3d 1328, 1334 (Fed. Cir. 2008) (“The equation thus does not disclose the
structure of the claimed device, but is only another way of describing the claimed function.”).
The Court agrees with the Defendants that the specification states that the language drivers 44
perform the function using “a database the key fields of which are an index field, a command
format field, and a response format field.” ‘236 Patent, 34:24–26.
The Court finds that the Defendants do not cite the entire portion of the specification that
discloses the means by which the language drivers 44 perform the function. The correct portion
of the specification is ‘236 Patent, 34:23 to 35:22, 35:31 to 37:10, and the figures referenced
therein.
The Court recognizes that this is a lengthy citation to the specification, but it is
necessitated by the fact that the patentee described in detail the structure that performs the
function. The first portion includes a detailed description of the language drivers 44 and how they
carry out the function. See ‘236 Patent, 34:23 to 35:8. The second portion describes in general
language how the language drivers 44 carry out the function:
The language drivers thus operate generally as follows. As described above,
the motion component 35 will call the 10 driver function implemented by the
language driver 44 and, in many cases, will pass parameters necessary to carry out
that function. The language driver 44 will use the index for that driver function to
look up the command format template and the response format template associated
with the appropriate driver function.
Using the command format template, the language driver 44 will construct
a command data string containing ASCII characters. The command data string
carries the commands and parameters necessary to implement the given driver 20
function in a desired manner on the motion control device 20 associated with the
language driver 44.
54 of 64
Id. at 35:8–22. The third portion sets forth four examples of how the language drivers 44 carry
out the function. Id. at 35:31 to 37:10.
1. Court’s Construction
The Court finds that “means for generating command data strings for controlling the
selected motion control device based on the command format template and the application
program” is a means-plus-function limitation with the function of “generating command data
strings for controlling the selected motion control device based on the command format template
and the application program,” and the structure of “language drivers 44 using a database, the
key fields of which are an index field, a command format field, and a response format field,
as identified in the ‘236 Patent at 34:23 to 35:22, 35:31 to 37:10, the figures referenced
therein, and equivalents thereof.”
D. “Means for Parsing Response Data Strings Generated by the Selected Motion Control Device
Based on the Response Format Template and the Application Program”28
Function: “parsing response data strings generated by the selected motion control device based on
the response format template and the application program”
Plaintiff’s Proposed Structure
Defendants’ Proposed Structure
“language driver using a database, the key fields
“software code that interprets response data
strings according to the response format template of which are an index field a command format
and then converts those strings into data types field and a response format field, as identified in
the ‘236 Patent at columns 35–37 and
supported by the application program, and
equivalents thereof”
equivalents”
This term is closely intertwined with the last term. The two functions of these terms work
hand in hand. For the instant term, the parties cite identical portions of the specification, and (as
with the last term) the parties identify language drivers 44 as the software modules identified in the
specification that carry out the function. See (Doc. No. 151, at 28) (citing ‘236 Patent, 35:23–26);
28. ‘236 Patent, claim 10.
55 of 64
(Doc. No. 157, at 28) (same). The parties’ arguments for this term mirror those raised for the last
term. RGB describes steps taken to perform the function and offers a generalized description of
the structure; the Defendants refer to the specification for the structure and argue that RGB’s
proffered construction is overly broad and generalized.
1. Analysis
As the parties correctly observe, the specification discloses that the instant function (like
the last function) is performed by the language drivers 44. ‘236 Patent, 35:23–26 (“[T]he
language driver 44 uses the response format template to parse a response data string sent by the
particular motion control device 20 in response to the command data string.”). As described
above, the specification states that the language drivers 44 operate using “a database the key fields
of which are an index field, a command format field, and a response format field.” ‘236 Patent,
34:24–26. As with the last term, the Court rejects RGB’s proposed structure because it simply
restates the function. See Aristocrat, 521 F.3d at 1334.
While the Court finds that the Defendants generally cite the correct portion of the
specification that discloses the means by which the language drivers 44 perform the function, a
more specific citation is ‘236 Patent, 34:23 to 35:16, 35:23 to 37:10, and the figures referenced
therein. The first portion of this citation includes a detailed description of the language drivers 44
and how they carry out the function. See ‘236 Patent, 34:23 to 35:8. The second portion
describes in general language how the language drivers 44 carry out the function:
The language drivers thus operate generally as follows. As described
above, the motion component 35 will call the 10 driver function implemented by
the language driver 44 and, in many cases, will pass parameters necessary to carry
out that function. The language driver 44 will use the index for that driver
function to look up the command format template and the response format template
associated with the appropriate driver function. . . .
Similarly, the language driver 44 uses the response format template to parse
a response data string sent by the particular motion control device 20 in response to
56 of 64
the command data string. The response format template thus allows the language
driver 44 to pass from the motion control device 20 to the motion control
component 35 any commands and/or parameters necessary to enable the
controlling application 26 to function as intended.
Id. at 35:8–16, 35:23–30. The third portion sets forth four examples of how the language drivers
44 carry out the function. Id. at 35:31 to 37:10.
2. Court’s Construction
The Court finds that “means for parsing response data strings generated by the
selected motion control device based on the response format template and the application
program” is a means-plus-function limitation with the function of “parsing response data strings
generated by the selected motion control device based on the response format template and the
application program,” and the structure of “language drivers 44 using a database, the key fields
of which are an index field, a command format field, and a response format field, as
identified in the ‘236 Patent at 34:23 to 35:16, 35:23 to 37:10, the figures referenced therein,
and equivalents thereof.”
E.
“Stream Control Means for Communicating the Control Commands to the Selected
Destination of Control Commands Based on the Transmit Stream Code Contained by the Stream
Associated with the Selected Destination of Control Commands”29
Function: “communicating the control commands to the selected destination of control
commands based on the transmit stream code contained by the stream associated with the selected
destination of control commands”
Plaintiff’s Proposed Structure
Defendants’ Proposed Structure
“software code responsible for sending and
“motion control drivers 30(a), 30(b), and 30(c)
retrieving data to and from a specific
as identified in the ‘236 Patent at column 8, line
destination—exemplified by the read and write 43–column 9, line 24 and equivalents thereof”
algorithms at ’236 Patent, 20:50–21:20, and their
equivalents.”
29. ‘236 Patent, claims 8, 9.
57 of 64
In Fanuc, Judge Folsom construed this term’s structure as “software code responsible for
sending and retrieving data to and from a specific destination—exemplified by the read and write
algorithms at ’236, 20:50[ to 21:20], and their equivalents.” Fanuc, No. 2:07-CV-418, 2009 U.S.
Dist. LEXIS 127428, at *89–90 (E.D. Tex. Aug. 25, 2009). RGB urges the Court to follow Judge
Folsom’s lead and construe the term’s structure in the same manner. (Doc. No. 151, at 29–30.)
The Defendants cite a separate potion of the specification, and state that this portion “in
combination with the passage cited by RGB make clear that the software drivers are the only
structure that perform the claimed function.” (Doc. No. 157, at 30) (citing ‘236 Patent, 8:43 to
9:24). The Defendants argue that RGB’s construction is too broad because it “encompasses any
software code that performs the function of sending and retrieving data to and from a specific
destination.” (Id.)
1. Analysis
The portions of the specification cited by both RGB and the Defendants refer to the
claimed function. The portion cited by RGB and employed by Judge Folsom in Fanuc, fall under
the relevant heading “Streams” and describe in a step-by-step manner the means by which control
commands are communicated using streams and stream code:
After opening a stream, it is ready to perform data transport operations. There are
two main data transport operations available: Reading data, and writing data.
FIG.30 describes the process of writing data to the stream. When writing to the
stream, the following steps occur. First the driver directs the stream to write data
to the target and passes the data to the stream. Next, the stream passes the data to
the CStreamDisp object. The CStreamDisp object passes the block of data to the
CIOMgr and directs it to write it to the target. The CIOMgr object either passes
the complete block of data to the CIOHAL object, or stores the block in an internal
buffer and then passes pieces of the buffer to the CIOHAL object until the complete
buffer is sent. The CIOHAL object takes the data passed to it and either sends it
directly to the target, passes it to a device driver, or calls COMM API to send the
data to the Serial 10 port. The device driver or COMM API sends the data directly
to the hardware controlled.
58 of 64
‘236 Patent, 20:50–67. The Court finds that this portion of the specification is clearly linked to
the claimed function and contains the algorithm that describes the means by which the function is
performed. However, the Court will not reference the last twenty lines cited by RGB, ‘236
Patent, 21:1–20, as these do not specifically disclose the means for the function at issue, but
instead are directed to the means-plus-function limitation in claim 9 of the ‘236 Patent that
involves the processing of response data. See ‘236 Patent, claim 9 (“A system as recited in claim
8, in which certain of the destinations of control commands generate response data, wherein: . . .
the stream control means processes the response data based on the response stream code.”); id. at
21:1–20 (describing in a step-by-step fashion the means by which response data is read from the
target using streams); Fanuc, 2009 U.S. Dist. LEXIS 127428, at *84–91 (finding that ‘236 Patent,
20:50 to 21:20 disclosed the structure for the means-plus-function limitations in both claims 8 and
9 of the ‘236 Patent). The Court also finds that the means for performing the function at issue is
disclosed in Figure 30 as cited within the above reference portion of the specification. See ‘236
Patent, Fig. 30; id. at 20:52–53 (“FIG.30 describes the process of writing data to the stream.”).
The portion of the specification which Defendants propose, ‘236 Patent, 8:43 to 9:24,
while referencing the function, simply presents a general description and preview of the function;
it does not disclose the means for performing the function as does ‘236 Patent, 20:50–67.
Compare ‘236 Patent, 8:43 to 9:24 (“The software system designer . . . will write transmit stream
code for each stream 28 that determines how the control commands are to be transferred to a given
one of the control command destinations . . . . [L]ater when run, the system 22 transfers the
control commands to the selected control command destination 16 and/or 34 based on the transmit
stream code in the stream 28 associated with the selected control command destination 16 and/or
34.”), with id. at 20:50–67 (“There are two main data transport operations available: Reading data,
59 of 64
and writing data. . . . When writing to the stream, the following steps occur.”). Furthermore,
while the Defendants cite to this separate portion of the specification, they do not take issue with
the portion cited by RGB and employed by Judge Folsom in Fanuc. (Doc. No. 157, at 30) (citing
‘236 Patent, 8:43 to 9:24). In fact, they essentially admit that this portion is linked to the function
by referencing it in support of their construction. Id. (“This statement, in combination with the
passage cited by RGB make clear that the software drivers are the only structure that perform the
claimed function . . . .”). The Court will not reference the portion of the specification cited by the
Defendants because it does specifically disclose the means for performing the function as does
‘236 Patent, 20:50–67.
Finally, the Court agrees with the Defendants that the specification makes clear that the
software drivers 30 are the structure that performs the claimed function. ‘236 Patent, 20:53–56
(“When writing to the stream, the following steps occur. First the driver directs the stream to
write data to the target and passes the data to the stream.”); id. at Fig. 30; see also id. at 20:9–13
(“Driver directed operations occur when each driver 30 uses the stream component 28 connected
to it. Remember, each stream component is used as the data transport layer. Each driver uses the
stream to transfer the motion control command data, it generates, to the output target.”).
2. Court’s Construction
The Court finds that “stream control means for communicating the control commands
to the selected destination of control commands based on the transmit stream code
contained by the stream associated with the selected destination of control commands” is a
means-plus-function limitation with the function of “communicating the control commands to the
selected destination of control commands based on the transmit stream code contained by the
stream associated with the selected destination of control commands,” and the structure of
60 of 64
“software drivers 30 as identified in the ‘236 Patent at 20:50–67, Figure 30, and equivalents
thereof.”
VI. Conclusion
The Court adopts the constructions set forth in this opinion for the terms of the
patents-in-suit. See also Appendix A. The parties are ordered that they may not refer, directly or
indirectly, to each other’s claim construction positions in the presence of the jury. Likewise, the
parties are ordered to refrain from mentioning any portion of this opinion, other than the actual
definitions adopted by the Court, in the presence of the jury. Any reference to claim construction
proceedings is limited to informing the jury of the definitions adopted by the Court.
SIGNED this 25th day of July, 2013.
_________________________
Zack Hawthorn
United States Magistrate Judge
61 of 64
Appendix A: Court’s Construction of Claim Terms
TERMS, PHRASES,
AND CLAUSES
COURT’S CONSTRUCTION
“code associated with a hardware device or group of related hardware
devices, which helps generate commands necessary to perform motion
control operations associated with at least some driver functions”
“control commands” “command codes in hardware language, which instruct a motion control
device to perform motion control operations”
“an intermediate software layer containing component code that is separate
“motion control
component”/ “motion and distinct from the application program and the software driver”
component”
“component function” “a hardware independent function that corresponds to a motion control
operation”
“one or more controller dependent software modules that support some core
“software driver”/
driver functions and are used to control a hardware device or group of
“driver”
related hardware devices”
“software code in the motion control component that associates at least
“component code”
some of the component functions with at least some of the driver functions”
No construction necessary.
“motion control”
“driver code”
“motion control
operation”/ “motion
operation”
“Hardware independent operations that are performed by a motion control
device.”
“primitive
operations”/
“primitive motion
operations”
“Motion control operations that cannot be simulated using a combination of
other motion control operations.”
“non-primitive
“Motion control operations that can be simulated using a combination of
operations”/
“non-primitive motion other motion control operations.”
operations”
“A device comprising a controller and a mechanical system capable of
“motion control
moving an object in a desired manner.”
device”
“application program
comprising a
“A software program designed to handle specific tasks.”
set/series of
component functions”
“Hardware independent functions that are separate and distinct from the
component functions.”
“core driver function” “A driver function associated with one of the primitive motion control
operations.”
“driver functions”
62 of 64
TERMS, PHRASES,
AND CLAUSES
“extended driver
function”
“network”
COURT’S CONSTRUCTION
“A driver function associated with one of the non-primitive motion control
operations.”
“A
communications and data exchange system created by connecting two
or more computers.”
“means for
Function: “determining a driver unit system employed by the software
determining a driver drivers.”
unit system employed
Structure: ““CDriverMgr object within motion component 34, as identified
by the software
in the ‘236 Patent at 11:15–19, 11:58 to 13:6, Figs. 6–7, and equivalents
drivers”
thereof.”
“means for converting Function: “converting an application unit system employed by the
an application unit
application program into the driver unit system.”
system employed by
Structure: “CUnitMapper object within motion component 34, as identified
the application
in the ‘236 Patent at 11:17–22, 12:19–21, 12:36–38, 12:43–58, Figs 6–7,
program into the
and equivalents thereof.”
driver unit system”
“means for generating Function: “generating command data strings for controlling the selected
command data strings motion control device based on the command format template and the
for controlling the
application program.”
selected motion
Structure: “language drivers 44 using a database, the key fields of which are
control device based
an index field, a command format field, and a response format field, as
on the command
identified in the ‘236 Patent at 34:23 to 35:22, 35:31 to 37:10, the figures
format template and
referenced therein, and equivalents thereof.”
the application
program”
“means for parsing Function: “parsing response data strings generated by the selected motion
response data strings control device based on the response format template and the application
generated by the
program.”
selected motion
Structure: “language drivers 44 using a database, the key fields of which are
control device based
an index field, a command format field, and a response format field, as
on the response format
identified in the ‘236 Patent at 34:23 to 35:16, 35:23 to 37:10, the figures
template and the
referenced therein, and equivalents thereof.”
application program”
63 of 64
TERMS, PHRASES,
AND CLAUSES
COURT’S CONSTRUCTION
“stream control means Function: “communicating the control commands to the selected
for communicating destination of control commands based on the transmit stream code
the control commands contained by the stream associated with the selected destination of control
to the selected
commands.”
destination of control
Structure: “software drivers 30 as identified in the ‘236 Patent at 20:50–67,
commands based on
Figure 30, and equivalents thereof.”
the transmit stream
code contained by the
stream associated with
the selected
destination of control
commands”
64 of 64
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?