GoDaddy.com LLC v. RPost Communications Limited et al
Filing
219
ORDER that the Court adopts the constructions, pursuant to Markman, as set forth in this Order for the disputed terms of the Tomkow and Feldbau Patents. FURTHER ORDERED that the parties may not refer, directly or indirectly, to each other's c laim construction positions in the presence of the jury. Likewise, the parties are ordered to refrain from mentioning any portion of this Order, 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. See order for complete details. Signed by Senior Judge James A. Teilborg on 1/19/16. (NKS)
1
WO
2
3
4
5
6
IN THE UNITED STATES DISTRICT COURT
7
FOR THE DISTRICT OF ARIZONA
8
9
GoDaddy.com, LLC,
10
Plaintiff,
11
ORDER
v.
12
No. CV-14-00126-PHX-JAT
RPost Communications Limited, et al.,
13
Defendants.
14
15
Before the Court is Defendants’1 Opening Claim Construction Brief (Doc. 114),
16
Plaintiff GoDaddy.com, LLC (“GoDaddy”)’s Responsive Claim Construction Brief
17
(Doc. 117), and Defendants’ Reply Claim Construction Brief (Doc. 119). On October 22,
18
2015, the Court conducted a Markman Hearing pursuant to Markman v. Westview
19
Instruments, Inc., 517 U.S. 370 (1996). Consistent with Markman, the Court now
20
construes the claims in the patents-at-issue: (1) U.S. Patent No. 8,161,104 (filed April 17,
21
2012) (the “’104 Patent”); (2) U.S. Patent No. 8,209,389 (filed June 26, 2012) (the “’389
22
Patent”); (3) U.S. Patent No. 8,224,913 (filed July 17, 2012) (the “’913 Patent”); (4) U.S.
23
Patent No. 8,468,198 (filed June 18, 2013) (the “’198 Patent”); (5) U.S. Patent
24
No. 8,468,199 (filed June 18, 2013) (the “’199 Patent”); and (6) U.S. Patent
25
No. 6,182,219 (filed January 30, 2001) (the “’219 Patent”).2
26
1
27
28
Defendants are RPost Communications Ltd.; RPost Holdings, Inc.; RPost
International Ltd.; and RMail Ltd. Defendants are collectively referred to as “RPost.”
2
The ’104, ’389, ’913, ’198, and ’199 Patents are referred to herein as the
“Tomkow Patents.” The ’219 Patent is referenced as the “Feldbau Patent.”
Table of Contents
1
2
3
I.
4
II. Legal Standard ......................................................................................................... 5
5
III. Table of Construed Terms for the Tomkow Patents ............................................ 8
6
IV. Table of Construed Terms for the Feldbau Patent .............................................. 19
7
V. Table of Construed Terms on Which the Parties Agree ...................................... 26
8
VI. Construction of Disputed Claim Terms in the Tomkow Patents ........................ 27
9
A. “message”............................................................................................................... 27
10
B. “server”................................................................................................................... 30
11
C. “a link” ................................................................................................................... 35
12
D. “an indication that the message has been opened by (delivered to) a
recipient” ..................................................................................................................... 36
13
Background .............................................................................................................. 4
14
E. “an indication of receipt of the message by the recipient (recipient
processor)” .................................................................................................................. 45
15
F. “an indication of the failure to deliver the message to the recipient” .................... 47
16
G. “executing the link when the message is opened at the recipient to control
the server to provide an indication that the message has been opened at the
recipient” ..................................................................................................................... 48
17
18
19
20
21
22
23
24
H. “the link being configured to execute automatically when the message is
opened at the recipient processor to control the server to provide an indication
at the server that the message has been opened at the recipient processor” ............... 53
I. “the link configured to execute when the link is activated at the recipient to
provide an indication that the message has been opened by (delivered to) a
recipient” ..................................................................................................................... 54
J. “executing the link when the link is activated at the recipient to control the
server to provide an indication that the message has been delivered to the
recipient” ..................................................................................................................... 56
26
K. “wherein the link is executed when the link is activated at the recipient to
control the server to provide an indication that the message has been opened at
(delivered to) the recipient” ........................................................................................ 57
27
L. “authenticatible information” ................................................................................. 58
28
M. “mail transport protocol dialog” ............................................................................ 62
25
-2-
1
2
3
4
5
N. “at least a portion of a mail transport protocol dialog (data transport dialog)
generated (by the electronic mail system) during transmission of the message
from the server to the recipient (processor)” .............................................................. 65
O. “SMTP and ESMTP protocol dialog”.................................................................... 67
P. “data transport dialog” ............................................................................................ 68
6
Q. “before the message is authenticated (any authentication of the message) by
the server” ................................................................................................................... 69
7
R. “Mail Transport Agent” ......................................................................................... 72
8
S. “sender” and “recipient” ......................................................................................... 74
9
T. “originating processor” and “recipient processor” ................................................. 77
10
U. “providing proof of receipt of the message by the recipient processor” ............... 80
11
V. “the link configured to execute when the message is opened at the recipient” ..... 84
12
W. “the server (being) displaced from the recipient (recipient processor)” ............... 84
13
X. “the server constructs authenticatible information related to the message” .......... 85
14
15
16
17
VII. Construction of Disputed Claim Terms in the Feldbau Patent ......................... 87
A. “authenticating the dispatch and (the) contents of the dispatch” ........................... 87
B. “authentication data” .............................................................................................. 92
C. “dispatch record data” ............................................................................................ 96
18
D. “an indicia of time of successful transmission of the dispatch to the
recipient” ..................................................................................................................... 99
19
E. “sender” and “recipient” ........................................................................................101
20
F. “processor for associating” ....................................................................................103
21
G. “means for providing an indicia of a time of successful transmission of the
dispatch to the destination receiving system, said time related indicia being
recorded by the authenticator and provided in a manner resistant to or
indicative of tampering by either of the sender and the recipient” ............................122
22
23
24
25
26
27
H. “means for securing at least part of the authentication data against
tampering by the sender and the recipient; wherein the processor is combined
with the means for securing” .....................................................................................127
I. “source transmitting system” and “destination transmitting system” ....................136
VIII. Conclusion ............................................................................................................139
28
-3-
1
I.
Background
2
The Tomkow Patents and Feldbau Patent claim, in broad terms, various systems
3
and methods for tracking, authenticating, and verifying the transmission, delivery or non-
4
delivery, opening, forwarding, content, and time events associated with an electronic
5
message.
6
The Tomkow Patents are all rooted in the same parent application, which issued as
7
U.S. Patent No. 7,966,372 (“’372 Patent”). Because the Tomkow Patents stem from the
8
‘372 Patent, they all share a similar specification and file history. The Field of Invention
9
for each Tomkow Patent is directed to “a system and method for verifying delivery and
10
content of an electronic message and, more particularly, to a system and method of later
11
providing proof regarding the delivery and content of an e-mail message.” ‘199 Patent
12
col. 1 ll. 22–26.
13
As a general overview of the individual Tomkow Patents, the ‘104 Patent
14
describes a system and method of verifying the opening of an electronic message sent
15
from a sender to a recipient through a server. The ‘389 Patent furnishes a system and
16
method to verify the receipt of an electronic message sent from a sender to a recipient
17
through a server. The ‘913 Patent sets forth a system and method of verifying the delivery
18
or non-delivery of an electronic message from a sender to a recipient through a server.
19
The ‘198 Patent—a continuation of the ‘104 Patent—claims a system and method of
20
verifying the opening and delivery of an electronic message sent from a sender to a
21
recipient through a server. Finally, the ‘199 Patent—a continuation of the ‘389 Patent—
22
provides a system and method of verifying the failure to deliver an electronic message
23
sent from a sender to a recipient through a server.
24
In a similar manner, the Feldbau Patent is disclosed as “a method and apparatus
25
for authenticating the dispatch and the contents of dispatched information in general.”
26
‘219 Patent col. 1 ll. 6–8. In other words, the Feldbau Patent provides an apparatus and
27
method of proving that the sender of a dispatch sent it to a particular recipient at a
28
particular time and that it had a particular content.
-4-
1
II.
Legal Standard
2
A patent includes two basic components: (1) a written description of the invention,
3
which is referred to as the “specification” of the patent, and (2) the patent claims. The
4
claims of a patent define the scope of the invention to which the patentee is entitled. See
5
Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc). “The purpose of
6
claim construction is to ‘determin[e] the meaning and scope of the patent claims asserted
7
to be infringed.’” See O2 Micro Int’l Ltd. v. Beyond Innovation Tech. Co., 521 F.3d 1351,
8
1360 (Fed. Cir. 2008) (citation omitted). Claim construction is a question of law
9
exclusively within the province of the Court. See Markman, 517 U.S. at 372. The Court
10
need only construe claims, however, when the parties raise a dispute about the proper
11
scope of a claim. O2 Micro, 521 F.3d at 1362. Moreover, if a disputed claim term has a
12
plain and ordinary meaning such that it needs no clarification or explanation, the Court
13
need not adopt a construction beyond that plain meaning. See U.S. Surgical Corp. v.
14
Ethicon, Inc., 103 F.3d 1554, 1568 (Fed. Cir. 1997).
15
When construing claims, the Court “look[s] to the words of the claims
16
themselves,” giving them “their ordinary and customary meaning” unless clearly stated
17
otherwise. Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996).
18
Claims should be considered as a whole, and terms used in multiple claims should be
19
construed consistently. See Inverness Med. Switz. GmbH v. Princeton Biomeditech Corp.,
20
309 F.3d 1365, 1371 (Fed. Cir. 2002). “[T]he ordinary and customary meaning of a claim
21
term is the meaning that the term would have to a person of ordinary skill in the art in
22
question at the time of the invention.” Phillips, 415 F.3d at 1313; see also Tex. Dig. Sys.,
23
Inc. v. Telegenix, Inc., 308 F.3d 1193, 1202 (Fed. Cir. 2002) (“The terms used in the
24
claims bear a ‘heavy presumption’ that they mean what they say and have the ordinary
25
meaning that would be attributed to those words by persons skilled in the relevant art.”).
26
“[T]here is no magic formula or catechism for conducting claim construction.”
27
Phillips, 415 F.3d at 1324. Rather, the Court “looks to those sources available to the
28
public that show what a person of skill in the art would have understood disputed claim
-5-
1
language to mean.” Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381
2
F.3d 1111, 1116 (Fed. Cir. 2004). “Those sources include the words of the claims
3
themselves, the remainder of the specification, the prosecution history, and extrinsic
4
evidence concerning relevant scientific principles, the meaning of technical terms, and
5
the state of the art.” Id. The Court is not “required to analyze [these] sources in any
6
specific sequence,” but may not use extrinsic evidence to contradict “claim meaning that
7
is unambiguous in light of the intrinsic evidence.” Phillips, 415 F.3d at 1324 (refining the
8
holding of Vitronics).
9
The specification “is the single best guide to the meaning of a disputed term.”
10
Power Integrations, Inc. v. Fairchild Semiconductor Int’l, Inc., 711 F.3d 1348, 1361
11
(Fed. Cir. 2013) (quoting Vitronics, 90 F.3d at 1582). The patentee may “act as its own
12
lexicographer,” Thorner v. Sony Comput. Entm’t Am. LLC, 669 F.3d 1362, 1365 (Fed.
13
Cir. 2012), by defining a claim term in the specification as having “a different meaning
14
than [it] would otherwise have to a person of ordinary skill in the art,” Innova/Pure
15
Water, 381 F.3d at 1116. See also Vitronics, 90 F.3d at 1582 (a specification “acts as a
16
dictionary when it expressly defines terms used in the claims or when it defines terms by
17
implication”). However, the Court will find the patentee to have acted as its own
18
lexicographer only if the patentee “clearly express[es] an intent to redefine the term.”
19
Thorner, 669 F.3d at 1365 (citation and internal quotation marks omitted).
20
Similarly, the specification may narrow the scope of a disputed claim term if the
21
patentee has “demonstrate[d] intent to deviate from the ordinary and accustomed
22
meaning of a claim term by including in the specification expressions of manifest
23
exclusion or restriction, representing a clear disavowal of claim scope.” Thorner, 669
24
F.3d at 1365 (quoting Teleflex, Inc. v. Ficosa N. Am. Corp., 299 F.3d 1313, 1325 (Fed.
25
Cir. 2002)). In ascertaining whether the patentee has disavowed the full scope of a claim,
26
the Court must not read limitations from the specification into the claims. See Teleflex,
27
299 F.3d at 1326 (citing Comark Commc’ns, Inc. v. Harris Corp., 156 F.3d 1182, 1186
28
(Fed. Cir. 1998)). In other words, the claims are not necessarily limited to the
-6-
1
embodiments disclosed in the specification and courts must not read limitations from the
2
specification into the claims. See SRI Int’l v. Matsushita Elec. Corp. of Am., 775 F.2d
3
1107, 1121 n.14 (Fed. Cir. 1985) (en banc). To avoid importing limitations, the court
4
must consider the purposes of the specification, which are to teach and enable those of
5
skill in the art to make and use the invention and to provide the best way for doing so. See
6
Phillips, 415 F.3d at 1317–18.
7
In addition to the specification, the Court considers “the patent’s prosecution
8
history, if it is in evidence.” Markman v. Westview Instruments, Inc., 52 F.3d 967, 980
9
(Fed. Cir. 1995) (en banc), aff’d, 517 U.S. 370 (1996). “The purpose . . . is to ‘exclude
10
any interpretation that was disclaimed during prosecution.’” Chimie v. PPG Indus., Inc.,
11
402 F.3d 1371, 1384 (Fed. Cir. 2005) (citation omitted). The prosecution history may
12
reveal that the patentee “has unequivocally disavowed a certain meaning to obtain [its]
13
patent.” Omega Eng’g, Inc. v. Raytek Corp., 334 F.3d 1314, 1324 (Fed. Cir. 2003). Thus,
14
the Court examines both the specification and prosecution history to ascertain whether
15
the patentee has disavowed the full scope of a claim term.
16
The Court may also consider extrinsic evidence to aid in its construction of
17
disputed claim terms. See Phillips, 415 F.3d at 1317–18. For example, “[d]ictionaries are
18
always available to the court to aid in the task of determining meanings that would have
19
been attributed by those of skill in the relevant art to any disputed terms used by the
20
inventor in the claims.” Tex. Dig. Sys., 308 F.3d at 1202 (citing Vitronics, 90 F.3d at 1584
21
n.6). Technical dictionaries are worthy of special note and constitute evidence of
22
understanding of persons of skill in the relevant art. See Linear Tech. Corp. v. Impala
23
Linear Corp., 379 F.3d 1311, 1320 (Fed. Cir. 2004). Dictionaries are particularly helpful
24
in claim construction because they “endeavor to collect the accepted meanings of terms,”
25
Phillips, 415 F.3d at 1318, but the Court should not elevate dictionaries to prominence
26
over the specification and claim language, see id. at 1319–24. If a term has more than one
27
plausible ordinary meaning, the court must consult the intrinsic record to identify which
28
of the possible meanings is most consistent with the use of the words by the inventor.
-7-
1
2
“server”
All asserted Ordinary
claims in all meaning.
Tomkow
Alternatively, “a
Patents
computer(s),
computer
program(s), or
computing
device(s) that
provide
resources to
other devices
across a
network”
3
“A link”
‘104 Patent
Claims 1 and
27 and their
dependent
claims;
2
3
4
5
6
7
8
9
10
11
12
13
14
16
18
19
20
21
22
23
24
Ordinary
“a set of
instructions that meaning.
directs one
computing
resource to
another”
“a server that is
separate from
the sender”
The Court does
not construe this
term.
all asserted
claims for
‘198 Patent
15
17
“the outgoing
server, separate
from the sender,
that creates an
attachment,
transmits the
attachment and
the message, and
stores the portion
of the mail
transport dialog
generated during
transmission of
the message”
4
“an indication
that the
message has
been opened by
(delivered to) a
recipient”
‘104 Patent
Claims 1 and
its dependent
claims;
‘198 Patent
Claims 1, 6,
18, and 32
and their
dependent
claims
“information
that indicates
that the message
has been opened
by (delivered to)
the recipient”
25
26
27
28
-9-
“confirmation (at
the server) that the
message content
was viewed by the
recipient”
“verifiable
information that
indicates that the
message has
been opened by
(opened at;
delivered to) the
recipient”
1
“information
that indicates
that the message
has been
received by the
recipient
(recipient
processor)”
“confirmation that
the message
content was
received by the
recipient”
“verifiable
information that
indicates that the
message was
received by the
recipient
(recipient
processor)”
‘199 Patent
Claim 1 and
its dependent
claims
“information
that indicates
that the message
has failed to be
delivered to the
recipient”
“confirmation that
the message
content was not
received by the
recipient”
“verifiable
information that
indicates the
failure to deliver
the message to
the recipient”
‘104 Patent
Claim 1 and
its dependent
claims
“executing the
link when the
message is
opened at the
recipient to
cause the server
to provide an
indication that
the message has
been opened at
the recipient”
“action by the
recipient when the
message is opened
at the recipient to
control the server
to provide proof
that the message
has been opened
at the recipient,
the proof
providing a legal
or other
evidentiary status
on par with, if not
superior to, that of
registered United
States mail”
“the link
executing on its
own when the
message is
opened at the
recipient to
control the
server to provide
verifiable
information that
indicates that the
message has
been opened at
the recipient”
5
“an indication All asserted
of receipt of the claims for
message by the ‘389 Patent
recipient
(recipient
processor)”
6
“an indication
of the failure to
deliver the
message to the
recipient”
7
“executing the
link when the
message is
opened at the
recipient to
control the
server to
provide an
indication that
the message has
been opened at
the recipient”
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
- 10 -
1
8
“the link being
configured to
execute
automatically
when the
message is
opened at the
recipient
processor to
control the
server to
provide an
indication at the
server that the
message has
been opened at
the recipient
processor”
‘104 Patent
Claim 27 and
its dependent
claims
“the link
programmed to
execute
automatically
when the
message is
opened at the
recipient to
cause the server
to provide an
indication at the
server that the
message has
been opened at
the recipient”
“[link configured
to execute
through] action by
the recipient when
the message is
opened at the
recipient to
control the server
to provide proof
that the message
has been opened
at the recipient,
the proof
providing a legal
or other
evidentiary status
on par with, if not
superior to, that of
registered United
States mail”
“the link being
configured to
execute
automatically
when the
message is
opened at the
recipient to
control the
server to provide
verifiable
information that
indicates at the
server that the
message has
been opened at
the recipient
processor”
9
“the link
configured to
execute when
the link is
activated at the
recipient to
provide an
indication that
the message has
been opened by
(delivered to)
the recipient”
‘198 Patent
Claims 1, 18,
and 32 and
their
dependent
claims
“the link
programmed to
execute when
the link is
activated at the
recipient to
provide an
indication that
the message has
been opened by
(delivered to)
the recipient”
“[link configured
to execute
through] action by
the recipient when
the message is
opened at the
recipient to
control the server
to provide proof
that the message
has been opened
at the recipient,
the proof
providing a legal
or other
evidentiary status
on par with, if not
superior to, that of
registered United
States mail”
“the link
configured to
execute when
the link is
activated at the
recipient to
provide
verifiable
information that
indicates that the
message has
been opened by
(delivered to)
the recipient”
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
- 11 -
1
2
3
4
5
6
7
8
10 “executing the
link when the
link is activated
at the recipient
to control the
server to
provide an
indication that
the message has
been delivered
to the recipient”
‘198 Patent
Claim 1 and
its dependent
claims
“executing the
link when the
link is called at
the recipient to
cause the server
to provide an
indication that
the message has
been delivered
to the recipient”
“[executing the
link through]
action by the
recipient when the
message is opened
at the recipient to
control the server
to provide proof
that the message
has been opened
at the recipient,
the proof
providing a legal
or other
evidentiary status
on par with, if not
superior to, that of
registered United
States mail”
“the link
executing on its
own when the
link is activated
at the recipient
to control the
server to provide
verifiable
information that
indicates that the
message has
been delivered
to the recipient”
11 “wherein the
link is executed
when the link is
activated at the
recipient to
control the
server to
provide an
indication that
the message has
been opened at
(delivered to)
the recipient”
‘198 Patent
Claims 18
and 32 and
their
dependent
claims
“wherein the
link is executed
when the link is
called at the
recipient to
cause the server
to provide an
indication that
the message has
been opened at
(delivered to)
the recipient”
“[link is executed
through] action by
the recipient when
the message is
opened at the
recipient to
control the server
to provide proof
that the message
has been opened
at the recipient,
the proof
providing a legal
or other
evidentiary status
on par with, if not
superior to, that of
registered United
States mail”
“wherein the
link is executed
when the link is
activated at the
recipient to
control the
server to provide
verifiable
information that
indicates that the
message has
been opened at
(delivered to)
the recipient”
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
- 12 -
1
2
3
12 “authenticatible ‘104 Patent
information”
Claim 1 and
its dependent
claims;
4
5
6
all asserted
claims for
‘198 Patent
“information
regarding the
content or
delivery of a
message that can
be verified”
“information
unique to the
message, the
digital signature
of the message,
and the portion of
the mail transport
dialog generated
during
transmission of
the message”
“information
unique to the
content or
delivery of a
message that can
be verified”
“mail transport
data including a
sequence of at
least one
command and at
least one
response”
“a list of
commands and
responses
exchanged
between servers
during
transmission of
the message that
is sufficient to
prove delivery of
the message to the
recipient,
providing a legal
or other
evidentiary status
on par with, if not
superior to, that of
registered United
States mail”
“data including
a sequence of at
least one mail
transport
protocol
command and at
least one mail
transport
protocol
response
exchanged
between devices
during
transmission of
the message”
7
8
9
10
11
12
13
13 “mail transport All asserted
claims for
protocol
‘389 Patent
dialog”
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
- 13 -
1
2
3
4
5
6
7
8
9
10
14 “at least a
portion of a
mail transport
protocol dialog
(data transport
dialog)
generated (by
the electronic
mail system)
during
transmission of
the message
from the server
to the recipient
(processor)”
All asserted
claims for
‘389 Patent;
15 “SMTP and
ESMTP
protocol
dialog”
All asserted
claims for
‘913 Patent
No further
construction
necessary
“a list of
commands and
responses
exchanged
between servers
during
transmission of
the message that
is sufficient to
prove delivery of
the message to the
recipient,
providing a legal
or other
evidentiary status
on par with, if not
superior to, that of
registered United
States mail”
“data including
at least one mail
transport
protocol
command or at
least one mail
transport
protocol
response
exchanged
between devices
during
transmission of
the message”
“SMTP or
ESMTP data
including a list
of at least one
command and at
least one
response
generated by the
electronic mail
system during
transmission of
the message
from the server
to the recipient”
“a list of
commands and
responses
exchanged
between servers
during
transmission of
the message that
is sufficient to
prove delivery of
the message to the
recipient,
providing a legal
or other
evidentiary status
on par with, if not
superior to, that of
registered United
States mail”
“SMTP or
ESMTP data
including a list
of at least one
protocol
command and at
least one
protocol
response
exchanged
between devices
during
transmission of
the message”
‘199 Patent
Claim 1 and
its dependent
claims
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
- 14 -
1
2
“transport data
including a
sequence of at
least one
command and at
least one
response”
“a list of
commands and
responses
exchanged
between servers
during
transmission of
the message that
is sufficient to
prove delivery of
the message to the
recipient,
providing a legal
or other
evidentiary status
on par with, if not
superior to, that of
registered United
States mail”
“transport data
including a list
of at least one
command and at
least one
response
exchanged
between devices
during
transmission of
the message”
“before the
content and
delivery of the
message is
proved (proving
the content and
delivery of the
‘199 Patent message) by the
Claim 1 and server”
its dependent
The plain
claims
language of this
phrase does not
require that any
authentication of
the message be
performed by
the server.
“before proving
the content and
delivery of the
message by
comparing and
matching
authenticable
information so as
to provide a legal
or other
evidentiary status
on par with, if not
superior to, that of
registered United
States mail”
“before the
content and
delivery of the
message is
proved (proving
the content and
delivery of the
message) by the
server”
16 “data transport
dialog”
‘199 Patent
Claim 1 and
its dependent
claims
17 “before the
message is
authenticated
(any
authentication
of the message)
by the server”
‘389 Patent
claims 1, 12,
14, and 15
and their
dependent
claims;
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
- 15 -
1
2
3
18 “Mail Transport All asserted
Agent”
claims for
‘913 Patent
4
5
“software that
transfers
electronic
messages from
one computer to
another”
6
7
8
All asserted Ordinary
claims in all meaning.
Tomkow
Alternatively:
Patents
“originator of a
message”
“the computer that “a combination
of (1) the user
originates the
that caused the
message”
computerized
device to
originate the
message and (2)
the
computerized
device itself”
20 “recipient”
All asserted Ordinary
claims in all meaning.
Tomkow
Alternatively:
Patents
“who the sender
intends to
receive the
message”
“the computer that
receives the
message at its
intended
destination”
10
11
12
13
14
16
17
18
19
20
“software that
resides on a
server and that
transfers and
receives
electronic
messages from
one computer to
or from another”
19 “sender”
9
15
“software that
resides on the
server and that is
dedicated to
transferring and
receiving
electronic
messages from
one computer to
or from another”
21
22
23
24
25
26
27
28
- 16 -
“a combination
of (1) the user
that the sender
intends to
receive the
message and (2)
the
computerized
device that
receives the
message”
1
2
21 “originating
processor”
“the computer that
‘104 Patent Ordinary
originates the
Claim 27 and meaning.
message”
its dependent
Alternatively:
claims;
“a computing
‘389 Patent device where the
Claim 7 and message
its dependent originates”
claims
22 “recipient
processor”
‘104 Patent Ordinary
Claim 27 and meaning.
its dependent
Alternatively:
claims;
“a computing
‘389 Patent device where the
Claim 7 and recipient
its dependent receives the
message”
claims
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
‘389 Patent
23 “providing
proof of receipt Claim 7
of the message
by the recipient
processor”
This phrase
appears in the
preamble and is
not limiting.
18
19
20
21
22
23
24
25
26
27
28
- 17 -
“the
computerized
device where the
message
originates”
“the computer that
receives the
message at its
intended
destination”
“the
computerized
device that
receives the
message”
“providing
evidence that
confirms receipt
of the message by
the recipient, the
evidence
providing a legal
or other
evidentiary status
on par with, if not
superior to, that of
registered United
States mail”
“proving that the
message was
received by the
recipient
processor”
1
2
3
4
5
‘104 Patent
Claims 1 and
27 and their
dependent
claims
“the link
programmed to
execute when
the message is
opened at the
recipient”
25 “the server
(being)
displaced from
the recipient
(recipient
processor)”
‘104 Patent
Claims 1 and
23 and their
dependent
claims;
Ordinary meaning The Court does
“the server
not construe this
(being) logically
term.
displaced from
the recipient
(recipient
processor)”
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
“[link configured The Court does
not construe this
to execute
through] action by term.
the recipient when
the message is
opened at the
recipient to
control the server
to provide proof
that the message
has been opened
at the recipient,
the proof
providing a legal
or other
evidentiary status
on par with, if not
superior to, that of
registered United
States mail”
24 “the link
configured to
execute when
the message is
opened at the
recipient”
‘389 Patent
Claims 1, 7,
14, and 15
and their
dependent
claims;
all asserted
claims for
‘199 Patent;
‘198 Patent
Claim 1 and
its dependent
claims
- 18 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2 “authentication All
data”
asserted
claims
“information that
is associated with
the contents of
the dispatch by
generating a
representation of
at least content
data, an indicia of
a time of
successful
transmission of
the dispatch to
the recipient, and
an indicia
relating to the
destination of the
dispatch, the
representation
comprising one
or more
elements”
15
16
17
18
19
20
21
22
23
24
25
26
27
28
- 20 -
“information that
is associated with
the contents of
the dispatch by
generating a
representation of
at least the
elements a1, a2
and a3, the
representation
comprising one
or more
elements”
“information that is
associated with the
contents of the
dispatch by
generating a
representation of at
least (1) content
data; (2) an indicia
of a time of
successful
transmission of the
dispatch to the
recipient, said
indicia being
recorded by an
authenticator and
provided in a
manner that is
resistant to or
indicative of
tampering by either
sender or recipient;
and (3) an indicia
relating to the
destination of the
dispatch; where the
representation is
comprised of one or
more elements”
1
2
3 “dispatch
record data”
All
asserted
claims
“information
relating to the
dispatch”
“data recorded by
the authenticator
during the
transmission of
the dispatch,
which includes at
least the time
related indicia
and the indicia
relating to the
destination of the
dispatch, and
which does not
include the
content data
representative of
the contents of
the dispatch”
“information
relating to the
dispatch but not
relating to content
data representative
of the contents of
the dispatch”
4 “an indicia of
time of
successful
transmission
of the dispatch
to the
recipient”
Claim 60
and its
dependent
claims
“data that
represents the
time at which the
dispatcher
forwarded the
dispatch for
delivery such that
the recipient may
later be able to
receive the
dispatch and
where the data is
obtained without
any cooperation
from the
recipient”
“data that
represents the
actual time at
which the
dispatcher
completed
transmission of
the dispatch for
delivery, such
that the recipient
may later be able
to receive the
dispatch and
where the data is
obtained without
any cooperation
from the
recipient”
“data that represents
the time at which
the dispatcher
forwarded the
dispatch for
delivery such that
the recipient may
later be able to
receive the dispatch
and where the data
is obtained without
any cooperation
from the recipient”
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
- 21 -
1
5 “sender”
All
asserted
claims
Ordinary
meaning
“a combination of
“the computer
that originates the (1) the user that
caused the
dispatch”
computerized
device to originate
the dispatch and (2)
the computerized
device itself”
6 “recipient”
All
asserted
claims
Ordinary
meaning
“the computer
that receives the
dispatch at its
intended
destination”
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
- 22 -
“a combination of
(1) the user that the
sender intends to
receive the message
and (2) the
computerized
device that receives
the message”
1
2
3
4
5
7 “processor for Claim 82
associating”
and its
dependent
claims
Ordinary
meaning; claim
term is not
indefinite and is
not subject to 35
U.S.C. §112(6)
6
7
8
Indefinite.
Function:
associating the
content data with
dispatch record
data and
generating the
authentication
data
Claim term is
subject to 35 U.S.C.
§112(6).
Function:
Associating the
content data with
dispatch record data
and generating the
authentication data.
Structure: None. Structure: A
function executor
102, which may be
a Microchip
Technology Inc.’s
PIC16C5x series
EPROM-based
micro-controller,
that associates a set
of information
elements (“A”) by
applying an
association function
(“F”) to generate
another set of
information
elements (“B”), i.e.,
B=F(A); and its
equivalents.
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
- 23 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
8 “means for
providing an
indicia of a
time of
successful
transmission
of the dispatch
to the
destination
receiving
system, said
time related
indicia being
recorded by
the
authenticator
and provided
in a manner
resistant to or
indicative of
tampering by
either of the
sender and the
recipient”
Claim 82
and its
dependent
claims
Function:
Providing an
indicia of a
time of
successful
transmission
of the
dispatch to
the
destination
receiving
system, said
time related
indicia being
recorded by
the
authenticator
and provided
in a manner
resistant to or
indicative of
tampering by
either of the
sender and the
recipient
Structure:
(1) Internal
clock 50 (2)
Communicati
ons network
server
(3) Secure
time
generator 104
(4) Digital
Notary
System
(DNS); and
their
equivalents
28
- 24 -
Function:
Agreed to by
the parties.
Structure: A
secure clock
internal to the
authenticator or
a time stamping
service such as
the Digital
Notary System
(DNS) external
to the
authenticator
that is secured
from being set
or modified by
an interested
party such as
the sender.
Function: Providing an
indicia of a time of
successful transmission
of the dispatch to the
destination receiving
system, said time
related indicia being
recorded by the
authenticator and
provided in a manner
resistant to or indicative
of tampering by either
of the sender and the
recipient.
Structure: Either a (1)
securable clock 50 and
equivalents thereof; (2)
time generator 104 and
equivalents thereof; (3)
communications
network server and
equivalents thereof; or
(4) Time Stamping
Service, such as the
Digital Notary System,
and equivalents thereof;
where structures (1) and
(2) are internal to the
authenticator, structures
(3) and (4) are external
to the authenticator, and
structures (2), (3) and
(4) are secured from
being set or modified by
an interested party such
as the sender.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
9 “means for
securing at
least part of
the
authentication
data against
tampering by
the sender and
the recipient;
wherein the
processor is
combined with
the means for
securing”
Claim 82
and its
dependent
claims
Function: Securing
Function:
Agreed to by the at least part of the
authentication data
parties.
against tampering
Structure: Using by either the sender
or the recipient.
a compression,
private or public
key encryption or Structure: Storing
the data either (1)
scrambling
on a write-once
technique, a
Structure:
read-many
Storage unit 54 password, or a
(“WORM”) device
or storage device combination
thereof, such as such as an optical
106, and their
those employed disk or a
equivalents
Programmable
by the widely
Read-Only Memory
used RSA
(“PROM”) device;
encryption
method, and by or (2) using a
the PKZIIP(tm) compression,
private or public
program from
PKWARE Inc., key encryption or
Glendale, Wis., scrambling
technique, a
U.S.A., and
password, or a
where the
combination
“securing”
procedure, key or thereof, such as
those employed by
password are
unknown to any the widely used
interested party. RSA encryption
method, and by the
PKZIIP(tm)
program from
PKWARE Inc.,
Glendale, Wis.,
U.S.A., and where
the “securing”
procedure, key or
password are
unknown to any
interested party.
Function:
Securing at least
part of the
authentication
data against
tampering by
either the sender
or the recipient
28
- 25 -
1
2
VI.
Construction of Disputed Claim Terms in the Tomkow Patents
A.
“message” (Term No. 1)
1.
3
The Parties’ Positions
4
RPost argues that the claim term “message” should be construed as “an electronic
5
message.” (Doc. 191-1 at 1). RPost explains that Judge Rodney Gilstrap of the Eastern
6
District of Texas (“EDTX”) construed “message” as “an electronic message” and urges
7
the Court to adopt the same construction. (Doc. 114 at 7–8).5
8
In response, GoDaddy agrees that “message” should be construed as “electronic”
9
but disputes the adequacy of that description. (Doc. 117 at 6–7). Specifically, GoDaddy
10
maintains that “message” should also be limited by how the message is transmitted
11
(“through an electronic network”) and by its singularity (“as a whole”). (Id.) To support
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
5
Many of the disputed terms in this case were construed by Judge Gilstrap in
2013. See RMail Ltd. v. Amazon.com, Inc., 2013 WL 968246 (E.D. Tex. Mar. 12, 2013).
At issue before Judge Gilstrap was the Feldbau Patent; the ‘372 Patent; and U.S. Patent
No. 7,865,557 (“’557 Patent”), which is a division of the ‘372 Patent. Several of the
Tomkow Patents (‘104, ‘389, ‘198, and ‘199 Patents) are continuations of the ‘372
Patent, while the ‘913 Patent is a division of the ‘557 Patent.
One of the disputed terms in the Feldbau Patent was also construed by Judge
James Selna of the Central District of California in Propat Int’l Corp. v. RPost Inc., 2005
WL 6287844 (C.D. Cal. Jan. 14, 2005) (“Propat”). All substantive rulings in Propat were
subsequently vacated, however, when the court determined that the plaintiff, Propat
International Corporation, lacked standing. See Propat Int’l Corp. v. RPost Inc., 2005
WL 6233792 (C.D. Cal. Nov. 28, 2015).
For many of the thirty-seven disputed terms in this case, a party advocates that the
Court should adopt a construction as crafted by Judge Gilstrap or Judge Selna. Even if
these constructions were from this district, however, they would not be binding on the
Court. The cases before Judge Gilstrap and Judge Selna involved different defendants,
making issue preclusion inapplicable here. There is, nonetheless, an interest in stare
decisis and uniformity in treatment of the same patent. See Markman, 517 U.S. at 390–
91. Prior constructions may be used as persuasive precedent, but that does not foreclose
the Court from reaching a different conclusion. See Verizon Cal. Inc. v. Ronald A. Katz
Licensing, L.P., 326 F. Supp. 2d 1060, 1069 (C.D. Cal. 2003); Nilssen v. Motorola, Inc.,
80 F. Supp. 2d 921, 924 n.4 (N.D. Ill. 2000). Consequently, the Court will consider the
prior constructions of Judge Gilstrap and Judge Selna but only for their persuasive value.
- 27 -
1
these added limitations, GoDaddy observes that the shared specification discloses that the
2
invention “may apply to any electronic message that can be transmitted through an
3
electronic message network.” (Id. at 7 (quoting ‘199 Patent col. 27 ll. 26–32)). GoDaddy
4
further contends that a “message” must be sent “as a whole” because the term “message”
5
is always preceded in the claims by the articles “a” or “the.” (Id.) GoDaddy therefore
6
proposes a construction of: “an electronic message that can be transmitted as a whole
7
through an electronic network.” (Doc. 191-1 at 1).
8
RPost replies that GoDaddy’s “as a whole” limitation is unsupported by the
9
intrinsic record and will confuse the jury. (Doc. 119 at 3). RPost also contends that
10
GoDaddy’s “cherry-picked” limitation of “through an electronic network” does not
11
describe a feature of the message and also neglects to include a second transmission
12
method disclosed in the same sentence of the specification. (Id. at 4).
13
14
15
16
17
2.
Analysis
The term “message” is used in all asserted claims of the Tomkow Patents. For
example, the ‘199 Patent claims:
1. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
18
receiving the message at the server from the sender;
19
transmitting the message to the recipient
20
...
21
22
23
24
25
26
27
receiving at the server from the recipient an indication of the failure
to deliver the message to the recipient . . . .
‘199 Patent col. 27 ll. 58–65 (emphasis added). Another example is found in the ‘198
Patent which claims:
1. A method of transmitting a message from a sender to a recipient
and providing an indication that the message was opened by the recipient,
comprising:
receiving the message at a server from the sender, the server being
displaced from the recipient,
28
- 28 -
1
associating a link with the message by the server . . .
2
transmitting the message . . . from the server to the recipient . . . .
3
‘198 Patent col. 28 ll. 6–16 (emphasis added).
4
Because the parties do not dispute that “message” should be construed as
5
“electronic,” the Court will, at a minimum, adopt RPost’s proposed construction of “an
6
electronic message.” The remaining question is whether “an electronic message” should
7
be cloaked with the limitations proposed by GoDaddy.
8
Regarding GoDaddy’s first proposed limitation “as a whole,” the Court is not
9
persuaded by GoDaddy’s argument that because certain articles precede “message” in the
10
claim language, there is somehow a requirement that the message must be sent “as a
11
whole.” Beyond referencing the claims’ use of “a” and “the,” GoDaddy does not cite any
12
other portion of the intrinsic record to show that “a message” cannot be transmitted in
13
multiple components. Accordingly, the Court rejects this portion of GoDaddy’s proposal
14
because it would ambiguously construe a readily understandable term.
15
As to GoDaddy’s second proposed limitation “through an electronic network,” the
16
Court finds that such a limitation is not supported by the intrinsic record. The asserted
17
claims of the Tomkow Patents do not require that messages be transmitted only through
18
electronic networks. In fact, the portion of the shared specification relied upon by
19
GoDaddy actually sets forth two means of transmitting a message. See ‘199 Patent col. 27
20
ll. 26–32 (“Although the above generally describes a system and method of verifying that
21
an e-mail was sent and/or received, the present invention may apply to any electronic
22
message that can be transmitted through an electronic message network or through an
23
electronic gate.” (emphasis added)). GoDaddy, without explanation, severed the
24
“electronic gate” transmission method in its proposal. In any event, the Court finds that
25
appending this method of transmission limitation to “message” is needlessly redundant
26
considering the parties agree that “message” must be “electronic.” Thus, the Court rejects
27
this portion of GoDaddy’s proposed construction.
28
- 29 -
1
2
3
4
For these reasons, the Court adopts RPost’s proposal and construes “message” as
“an electronic message.”
B.
“server” (Term No. 2)
1.
The Parties’ Positions
5
RPost recommends that the Court should shadow Judge Gilstrap and abstain from
6
construing the term “server.” (Doc. 114 at 8–9). Judge Gilstrap concluded that defining
7
“server” was unnecessary because the term had been used by the asserted claim
8
according to its plain and ordinary meaning. See RMail, 2013 WL 968246, at *60. RPost
9
also advances an alternative construction: “a computer(s), computer program(s), or
10
computing device(s) that provides resources to other devices across a network.”
11
(Doc. 191-1 at 1). This alternative construction closely tracks RMail’s proposal that
12
Judge Gilstrap rejected as “not derived from intrinsic evidence.” RMail, 2013 WL
13
968246, at *60.
14
GoDaddy responds that “server” must be interpreted because there is “no plain
15
meaning that resolves the parties’ dispute.” (Doc. 117 at 7–8). According to GoDaddy,
16
“server” must: 1) be “outgoing”; 2) be “separate from the sender”; 3) “create an
17
attachment”; 4) “transmit the attachment and message”; and 5) “store the portion of the
18
mail transport dialog generated during transmission of the message.” (Id.)
19
RPost replies that GoDaddy’s limitations are improper because they “cannot apply
20
to all of the claims.” (Doc. 119 at 4). RPost also contends that GoDaddy’s limitations are
21
ambiguous and unsupported by the intrinsic record. (Doc. 114 at 8–9).
22
23
24
25
26
2.
Analysis
The term “server” is used by all asserted claims of the Towkow Patents but is not
defined or explained within the intrinsic record. A few examples include:
1. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
27
receiving the message at the server from the sender
28
...
- 30 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
receiving at the server at least a portion of a mail transport protocol
dialog generated during transmission of the message from the server to the
recipient; and
receiving at the server from the recipient an indication of the receipt
of the message by the recipient;
forming at the server a first information from the at least a portion of
the mail transport protocol dialog and the indication of the receipt of the
message by the recipient; and
transmitting, before any authentication of the message, a copy of the
message and the first information to the sender from the server.
‘389 Patent col. 27 ll. 58–col 28 ll. 7 (emphasis added).
7. A system for transmitting a message through an electronic mail
system from an originating processor to a recipient processor and providing
proof of receipt of the message by the recipient process, comprising:
a server displaced from the originating processor, the server capable
of being configured by software commands . . . .
Id. col. 28 ll. 33–39 (emphasis added).
32. A system transmitting a message from a sender to a recipient and
providing an indication that the message was opened by the recipient,
comprising:
a server in electronic communication with the sender and receiver,
the server programmed to receive a message from the sender, to associate a
link with the message, the link configured to execute when the link is
activated at the recipient to provide an indication that the message has been
delivered to a recipient, to transmit the message and the link from the
server to the recipient, wherein
the link is executed when the link is activated at the recipient to
control the server to provide an indication that the message has been
delivered to the recipient; and
wherein the server is programmed to form an authenticatible
information related to the message, and to transmit the indication of the
delivery of the message to the recipient and the authenticatible information
from the server to the sender.
‘198 Patent col. 30 ll. 7–25 (emphasis added).
1. A method of transmitting a message from a sender to a recipient
through a server acting as a Mail Transport Agent, including the steps at the
server of:
- 31 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
...
Recording at the server some portion of the selected one of the
SMTP and ESMTP protocol dialog between the server and the recipient
through the server including those portions of the selected one of the SMTP
and ESMTP protocol dialog between the server and the recipient in which
the receiving Mail Transport Agent accepts or declines delivery of the
transmitted message.
‘913 Patent col. 27 ll. 41–54 (emphasis added).
Initially, despite GoDaddy’s argument that no “plain meaning” of “server”
resolves the parties’ dispute, GoDaddy does not raise an actual dispute concerning the
plain meaning of the term. Particularly, GoDaddy’s proposed construction includes the
word “server” and shrouds it with five limitations. For example, GoDaddy’s proposal
states that “server” must be an “outgoing server.” While this construction limits “server”
as “outgoing,” it does not raise an actual dispute as to the “plain meaning” of the word
“server.” Likewise, the balance of GoDaddy’s proposal affixes several limitations to
“server” without challenging the plain meaning of the term. Accordingly, the question
presented by GoDaddy is not whether the plain meaning of “server” is disputed, but
whether the proposed limitations should be levied upon the term.
The Court will review each of GoDaddy’s proposed limitations in turn.
a.
“outgoing server”
GoDaddy proposes that “server” must be construed as “outgoing server” but does
not cite to the intrinsic record for support. See (Doc. 117 at 3–4). The Tomkow Patents,
however, consistently specify that the server can both receive and transmit messages. See,
e.g., ‘389 Patent col. 27 ll. 59–61 (claiming “steps at the server comprising: receiving the
message at the server from the sender . . . .”). If GoDaddy intended to limit “server” to
only servers that send messages and not ones that receive messages, such a construction
violates the intrinsic record. In absence of more compelling evidence, the Court rejects
GoDaddy’s proposed limitation of “outgoing.”
27
28
- 32 -
1
b.
“separate from the sender”
2
GoDaddy also proposes that “server” should be limited as “separate from the
3
sender.” (Doc. 117 at 7–8). RPost’s sole dispute with this limitation is that it is redundant
4
because “server” and “sender” are “distinct claim elements.” (Doc. 114 at 9). RPost
5
observes that several courts have spurned—on “redundancy” grounds—constructions that
6
incorporate language from the claim itself. (Doc. 119 at 4 (citing Interdigital
7
Commuc’ns., Inc. v. ZTE Corp., 2014 WL 3908771, at *1 (D. Del. Aug. 8, 2014); Asetek
8
Holdings, Inc. v. Coolit Sys., 2013 WL 6327691, at *4 (N.D. Cal. Dec. 3, 2013); Ferring
9
B.V. v. Watson Labs., Inc., 2013 WL 499158, at *7 (D. Nev. Feb. 6, 2013)). The Federal
10
Circuit, however, rejected the robotic application of such a stringent rule. See 01
11
Communique Lab., Inc. v. LogMeIn, Inc., 687 F.3d 1292, 1296 (Fed. Cir. 2012)
12
(“[Plaintiff] argues that because those functions are set forth expressly in the claim, it
13
would be ‘redundant and unnecessary’ to incorporate them into the construction of
14
‘location facility.’ However, [Plaintiff] has not cited, and we have not discovered, any
15
authority for the proposition that construction of a particular claim term may not
16
incorporate claim language circumscribing the meaning of the term. The claim language
17
makes clear that the location facility in fact does perform the functions in question. The
18
district court correctly incorporated those functions into its claim construction.”). Thus,
19
RPost’s “redundancy” argument, while persuasive, is not binding on the Court.
20
RPost never disputes that the claimed “server” is, in fact, “separate from the
21
sender,” and on balance, the Court concludes that construing “server” with the limitation
22
“separate from the sender” would be more helpful to the jury than a plain meaning
23
construction. The Court therefore adopts this portion of GoDaddy’s construction.
24
25
26
27
28
c.
“creates an attachment, transmits the attachment and
the message”
As a third limitation, GoDaddy argues that the server “creates an attachment [and]
transmits the attachment and the message.” (Doc. 117 at 8). GoDaddy, however, does not
point to claim language that requires the server to “create” or “transmit” an “attachment.”
- 33 -
1
The only claim language cited by GoDaddy concerns the role of the processor to
2
“associate a link with the message” or “add[] a link to the message,” but these claims are
3
all dependent claims. (Id. (citing ‘198 Patent col. 28 ll. 6–25, col. 29 ll. 13–19; ‘104
4
Patent col. 27 ll. 66–col. 28 ll. 4, col. 31 ll. 24–37)). GoDaddy does not explain why the
5
Court should interpret “link” as “attachment” or how “associate” or “add” is analogous to
6
“creates.” Without a more compelling reason for construing “server” with a limitation
7
found only in dependent claims, the Court rejects this portion of GoDaddy’s proposal.
8
See Liebel-Flarsheim Co. v. Medrad, Inc., 358 F.3d 898, 910 (Fed. Cir. 2004) (“[T]he
9
presence of a dependent claim that adds a particular limitation raises a presumption that
10
the limitation in question is not found in the independent claim.” (citing Wenger Mfg.,
11
Inc. v. Coating Mach. Sys., Inc., 239 F.3d 1225, 1233 (Fed. Cir. 2001))).
12
Regarding the balance of this third limitation, the claim language is clear that the
13
server “transmits” the message. See, e.g., ‘198 Patent col. 28 ll. 15–16, col. 29 ll. 13–19.
14
Accordingly, the Court rejects this part of GoDaddy’s proposal as needlessly redundant.
d.
15
16
17
18
19
20
21
22
23
24
25
“stores the portion of the mail transport dialog generated
during transmission of the dispatch”
As a fourth limitation, GoDaddy insists that the construction must include that the
server “stores the portion of the mail transport dialog generated during transmission of
the dispatch.” (Doc. 117 at 8). During the Markman Hearing, GoDaddy explained that the
server must store this information to later verify the message.
Only two asserted claims recite that the server stores any portion of the mail
transport dialog, and both are dependent claims found in only one Tomkow Patent. See
‘389 Patent, Claims 12 and 14.6 Had the inventor wanted to limit any of the asserted
independent claims in this manner, he certainly could have done so. As quoted above, the
Federal Circuit has held, “the presence of a dependent claim that adds a particular
26
27
28
6
The “storing” function is also found in asserted claims of the ‘913 Patent and
‘199 Patent, but neither relates to “mail transport dialog” and both are dependent claims.
See ‘913 Patent, Claim 2; ‘199 Patent, Claim 2.
- 34 -
1
limitation raises a presumption that the limitation in question is not found in the
2
independent claim.” Liebel-Flarsheim, 358 F.3d at 910 (citing Wenger Mfg., 239 F.3d at
3
1233). Further, “where the limitation that is sought to be ‘read into’ an independent claim
4
already appears in a dependent claim, the doctrine of claim differentiation is at its
5
strongest.” Id.; see SunRace Roots Enter. Co., Ltd. v. SRAM Corp., 336 F.3d 1298, 1302–
6
03 (Fed. Cir. 2003) (the presumption that an independent claim does not have a limitation
7
that is introduced for the first time in a dependent claim “is especially strong when the
8
limitation in dispute is the only meaningful difference between an independent and
9
dependent claim, and one party is urging that the limitation in the dependent claim should
10
be read into the independent claim”); Wenger Mfg., 239 F.3d at 1233 (“Claim
11
differentiation . . . is clearly applicable when there is a dispute over whether a limitation
12
found in a dependent claim should be read into an independent claim, and that limitation
13
is the only meaningful difference between the two claims.”).
14
A claim term should be construed in a manner that can be applied to all claims.
15
See Inverness Med. Switz. GmbH, 309 F.3d at 1371. Here, for all but two dependent
16
claims, “server” is not limited to “storing” mail transport dialog. Moreover, none of the
17
asserted claims from the ‘104 and ‘198 Patents even use the term “mail transport protocol
18
dialog.” Accordingly, the Court rejects this portion of GoDaddy’s proposal.
3.
19
20
21
22
23
Conclusion
For these reasons, the Court construes “server” as “a server that is separate from
the sender.”
C.
“a link” (Term No. 3)
1.
The Parties’ Positions
24
RPost argues that “a link” should be construed as “a set of instructions that directs
25
one computing resource to another.” (Doc. 114 at 9–10). RPost claims that such an
26
interpretation is “fully supported by the intrinsic record.” (Id.)
27
28
- 35 -
1
GoDaddy responds that no construction is necessary because “a link” is a readily
2
understandable term to a skilled artisan. (Doc. 117 at 8). GoDaddy further contends that
3
RPost’s construction broadens the scope of “a link” contrary to the intrinsic record. (Id.)
4
RPost replies that GoDaddy “completely ignores that the Tomkow patents
5
describe links as akin to instructions.” (Doc. 119 at 5). RPost also states that a “person of
6
ordinary skill in the art would understand that links, such as URLs, may contain
7
commands, or instructions, that direct one computing resource to another.” (Id.)
2.
8
Analysis
9
The Court finds that a person of ordinary skill in the art would understand the
10
functions “a link” performs without additional construction. As RPost concedes: “[a]
11
person of ordinary skill in the art would understand that links, such as URLSs, may
12
contain commands, or instructions, that direct one computing resource to another.”
13
(Doc. 119 at 5). The internal record also makes clear that “a link” is “added to the
14
message by the server,” is “configured to execute when the message is opened” in order
15
to “provide an indication that the message has been opened.” ‘104 Patent col. 28 ll. 1–4,
16
col. 31 ll. 25–31; ‘198 Patent col. 28 ll. 11–14, col. 29 ll. 14–19. If a disputed claim term
17
has a plain and ordinary meaning such that it needs no clarification or explanation, the
18
Court need not adopt a construction beyond that plain meaning. See U.S. Surgical, 103
19
F.3d at 1568. RPost failed to cite any portion of the intrinsic record to show that “a link”
20
was used in a way other than its plain meaning.
21
For these reasons, the Court does not construe this term.
22
D.
23
24
25
26
27
28
“an indication that the message has been opened by (delivered to) a
recipient” (Term No. 4)
1.
The Parties’ Positions
RPost argues that “indication” should be broadly interpreted as “information that
indicates” and supports its position by citing the Meriam Webster Dictionary. (Doc. 114
at 10). RPost thus proposes a construction of “information that indicates that the message
has been opened by (delivered to) a recipient.” (Doc. 191-1 at 1).
- 36 -
1
GoDaddy responds that RPost’s “circular” definition should be rejected. (Doc. 117
2
at 9). Instead, GoDaddy proposes a construction of “confirmation (at the server) that the
3
message content was viewed by the recipient.” (Doc. 191-1 at 1). To buttress its
4
definition of “indication” as “confirmation,” GoDaddy heavily relies on Figure 8 of the
5
‘199 Patent and its corresponding description. (Doc. 117 at 9). Figure 8—a preferred
6
embodiment of the ‘199 Patent—depicts the invention as sending a “confirmation
7
message” to the sender, which provides “verifiable confirmation” that the message was
8
received at a certain time, by a certain network route, and with specific content. ‘199
9
Patent Fig. 8, col. 25 ll. 49–col. 26 ll. 5. GoDaddy insists that the claimed “indication”
10
must have “certainty of content and provenance.” (Doc. 117 at 9). GoDaddy also defines
11
“opened” as “viewed” because, according to the specification, “the message is opened for
12
reading,” and GoDaddy argues that a message cannot be read without at some point being
13
viewed. (Id. at 10).
14
RPost argues that GoDaddy’s proposal is a shrewd and misguided attempt to
15
narrow the plain meaning of the claimed “indication.” See (Docs. 114 at 10; 119 at 5–6).
16
According to RPost, the patentee intentionally claimed “indication” in a broad manner
17
and “[a]bsent a clear disavowal in the specification or the prosecution history, the
18
patentee is entitled to the full scope of its claim language.” (Doc. 119 at 6 (citing Home
19
Diagnostics, Inc. v. LifeScan, Inc., 381 F.3d 1352, 1358 (Fed. Cir. 2004))). RPost
20
contends that the patentee did not make a “clear disavowal” of the full meaning behind
21
“indication,” and thus, GoDaddy’s proposal improperly imports a limitation from the
22
specification into the claim. (Doc. 114 at 10). RPost further observes that Figure 8’s
23
corresponding description “undermines” GoDaddy’s argument because “confirmation
24
message 72” is an “optional message” that “may or may not include verifiable
25
information” and can merely be a “simple text message indicating that a message was
26
received.” (Doc. 119 at 5). Finally, RPost complains that GoDaddy’s construction of
27
“opened” as “viewed” is improper because it narrows the meaning of the term without
28
adequate intrinsic record support. (Doc. 114 at 10).
- 37 -
1
2.
Legal Standard
2
A fundamental principle for discerning a term’s usage is the ordinary and
3
accustomed meaning of the words amongst artisans of ordinary skill in the relevant art at
4
the time of invention. See Rexnord Corp. v. Laitram Corp., 274 F.3d 1336, 1342 (Fed.
5
Cir. 2001). Normal rules of usage suggest a “heavy presumption” that claim terms carry
6
their accustomed meaning in the relevant community at the relevant time. CCS Fitness,
7
Inc. v. Brunswick Corp., 288 F.3d 1359, 1366 (Fed. Cir. 2002) (citing Johnson
8
Worldwide Assocs. Inc. v. Zebco Corp., 175 F.3d 985, 989 (Fed. Cir.1999)). Of course,
9
the Federal Circuit acknowledges that a patent applicant may overcome this presumption
10
by clearly using the words in the specification, prosecution history, or both “in a manner
11
inconsistent with its ordinary meaning.” Boehringer Ingelheim Vetmedica, Inc. v.
12
Schering–Plough Corp., 320 F.3d 1339, 1347 (Fed. Cir. 2003) (citing Teleflex, 299 F.3d
13
at 1325–26). In other words, an inventor may consistently and clearly use a term in a
14
manner either more or less expansive than its general usage in the relevant community,
15
and thus expand or limit the scope of the term in the context of the patent claims. See
16
Ballard Med. Prods. v. Allegiance Healthcare Corp., 268 F.3d 1352, 1361 (Fed. Cir.
17
2001) (noting that an applicant may disclaim claim scope during prosecution); Cordis
18
Corp. v. Medtronic Ave, Inc., 511 F.3d 1157, 1177 (Fed. Cir. 2008) (“In order to
19
constitute binding surrenders of claim scope, the statements in question must be such that
20
a competitor would reasonably believe that the applicant had surrendered the relevant
21
subject matter.” (quotation omitted)).
22
3.
Analysis
23
This phrase is used in the ‘104 and ‘198 Patents as follows:
24
1. A method of transmitting a message from a sender to a recipient
and providing an indication that the message was opened by the recipient,
comprising:
25
26
...
27
28
- 38 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
adding a link to the message by the server, the link configured to
execute when the message is opened at the recipient to provide an
indication that the message has been opened by the recipient,
executing the link when the message is opened at the recipient to
control the server to provide an indication that the message has been
opened at the recipient,
providing an authenticatible information related to the message,
including the indication of the opening of the message at the recipient, at
the server,
transmitting the indication of the opening of the message at the
recipient, and the authenticatible information from the server to the sender,
‘104 Patent col. 27 ll. 63–col. 28 ll. 16 (emphasis added).
1. A method of transmitting a message from a sender to a recipient
and providing an indication that the message was opened by the recipient,
comprising:
...
associating a link to the message by the server, the link configured to
execute when the message is opened at the recipient to provide an
indication that the message has been opened by the recipient,
executing the link when the message is activated at the recipient to
control the server to provide an indication that the message has been
delivered to the recipient,
providing an authenticatible information related to the message,
including the indication of the delivery of the message at the recipient, at
the server,
transmitting the indication of the delivery of the message at the
recipient, and the authenticatible information form the server to the sender,
‘198 Patent col. 28 ll. 6–25 (emphasis added). The term “indication” is similarly used in
independent Claims 18 and 32 and dependent Claim 6 of the ‘198 Patent. See ‘198 Patent
col. 28 ll. 39–41, col. 29 ll. 11–28, col. 30 ll. 7–25.
The parties dispute the interpretation of three terms: “indication,” “opened,” and
“message.” The Court will analyze each in turn.
27
28
- 39 -
a.
1
“indication”
2
GoDaddy maintains that to differentiate the invention from prior art, “indication”
3
must be construed as “confirmation” because the specification states that the invention
4
provides “proof” of the delivery and content of the message. (Doc. 117 at 10). According
5
to GoDaddy, “RPost cites no authority for its bare proposition that the patentee ‘chose to
6
claim the invention’ as covering something more than ‘proof’ of a message’s delivery
7
and content.” (Id.) GoDaddy collaterally asserts that RPost’s construction of “indication”
8
defines the term by the term itself, thereby making the construction “circular” and
9
altogether unhelpful to the jury. (Id.)7
10
Contrary to GoDaddy’s argument, RPost cites the most significant authority of all:
11
the claim language. The “appropriate starting point” for “proper claim construction” is
12
“always the language of the asserted claim itself.” Comark Commc’ns, 156 F.3d at 1186
13
(citations omitted). In the asserted claims here, the patentee claimed the invention to
14
provide an “indication” not a “confirmation”—undisputedly a term with a narrower
15
scope. Generally, an “indication” is a generic piece of information that tends to show
16
(i.e., indicates) something else. See Random House Webster’s College Dictionary 669
17
(1999) (defining “indication” as “something serving to indicate; sign; token” and
18
“indicate” as “to be a sign of; betoken”). On the other hand, “confirmation” is verifying
19
or establishing the “truth, accuracy, validity, or genuineness of” something. See id. 279
20
(defining “confirmation” as “the act of confirming” and “confirm” as “to establish the
21
truth, accuracy, validity, or genuineness of; corroborate; verify”). The dispute here is
22
whether the specification limits the claimed “indication” to the tapered boundaries of
23
“confirmation.”
24
25
26
27
28
7
GoDaddy proposed similar “circular” constructions for “server” (Term No. 2)
and “authenticator” (agreed upon Term No. 2, Feldbau Patent). See (Doc. 191-1 at 1, 14
(construing “server” as “the outgoing server . . .” and “authenticator” as “a sub-system
that operates to authenticate a dispatch”).
- 40 -
1
To resolve this dispute, understanding the Tomkow Patents’ two-step
2
“verification” or “proof” process is essential. As an example, the ‘104 Patent claims a
3
system and method for verifying, i.e., proving, the opening of a message and the
4
message’s content. The first step commences when the sender originates the message and
5
transmits it to the recipient. Before the message reaches the recipient, however, it cyphers
6
through an RPost server whereupon certain information is recorded, such as a hashed
7
version of its contents. See ‘104 Patent col. 28 ll. 25–29. The RPost server also adds a
8
“link” to the message that executes when the message is opened by the recipient, id. col.
9
28 ll. 1–4, and creates and stores “authenticatible information” about the message, which
10
essentially identifies a particular message as unique, id. col. 28 ll. 10–12, col. 31 ll. 33–
11
34. The RPost server then forwards the message to the recipient. See id. col. 28 ll. 5–6.
12
When the recipient opens the message, the link executes and provides an “indication that
13
the message has been opened by the recipient.” See id. col. 28 ll. 7–9. To conclude the
14
first step, the RPost server sends a receipt to the sender which includes the “indication”
15
that the message was opened and other “authenticatible information.” See id. col. 28 ll.
16
13–15.
17
18
19
20
21
22
23
24
25
26
27
28
The second step involves the actual verification of the opening of the message and
its contents. This step is disclosed in the specification as follows:
Verification
In the event that the originator of a message requires evidence at a
later date that an e-mail was sent, delivered, and/or read, the originator
presents the receipt(s) for the message to the operators of the system.
For example, in order to prove that a particular message was sent
from sender 10 to recipient 18, sender 10 sends to RPost a copy of receipt
20 with a request to verify the information contained within the receipt.
This could be done by sending the receipt to a predefined mailbox at RPost,
e.g., verify@RPost.com. RPost then determines whether or not the receipt
is a valid receipt. A receipt is a valid receipt if the digital signature matches
the reminder of the receipt, and the message digests match the
corresponding respective portions of the original message. Specifically,
RPost performs the hash function on the various portions of the message
including the message body, the attachments, and the overall message
- 41 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
including the SMTP dialog and DSN reports, to produce one or more
message digest corresponding to the purposed message copy. RPost
compares the message digests in the purported copy, including the overall
message digest, with the message digests which RPost has computed from
the purported message copy. The overall message digest can be compared
by either decrypting the overall message digest received as the digital
signature in the purported receipt, or by encrypting the overall message
digest which was calculated from the purported message copy. If the
message digests including the digital signature match, then the receipt is an
authentic RPost-generated receipt. Assuming that a good hash function was
used and that the keys used in the cryptographic hash function and the
digital signature encryption algorithm have not been divulged to others, it is
virtually impossible that the receipt has been ‘forged’ by the person
presenting the receipt. That is, the receipt must have been a receipt that was
generated by RPost, and therefore the message contained in the receipt, the
to/from information, the date and time of delivery, the fact of successful
delivery, the route by which the message traveled, and any DSN
information contained within the receipt, must be a true copy of that
information and is accurate. RPost can then provide authentication,
verification, and confirmation of the information contained within the
receipt. This confirmation can take the form of an e-mail confirmation,
affidavit testimony from RPost employees familiar with the methods used
by RPost, live sworn testimony in depositions and in court, and other forms
of testimony. . . .
In sum, the system provides reliable evidence based on the testimony
of a disinterested third party that a particular message having a particular
content was sent, when it was sent, who sent it, who received it, when it
was opened for reading, and when it was deleted. . . .
‘104 Patent col. 16 ll. 63–col. 17 ll. 55.
21
As readily seen, the invention “verifies” the opening of a message and its contents
22
during the second step of the process—not the first step. The first step merely provides an
23
“indication” to the sender that the message was opened by the recipient. This two-step
24
process was claimed by the inventor and explained through the specification. Because the
25
intrinsic record is clear that the invention “confirms” nothing during the first step,
26
GoDaddy’s proposed construction of “confirmation” is internally inconsistent.
27
Furthermore, GoDaddy’s adoption of Figure 8’s terminology is misplaced.
28
Figure 8 is merely “another embodiment of the invention.” ‘104 Patent col. 25 ll. 14–15.
- 42 -
1
If the Court were to adopt GoDaddy’s proposal, it would be reading a limitation from the
2
specification into the claim—a “cardinal sin” according to the Federal Circuit. Teleflex,
3
299 F.3d at 1326 (citing Comark Commc’ns, 156 F.3d at 1186); see Tex. Instruments, Inc.
4
v. United States Int’l Trade Comm’n, 805 F.2d 1558, 1563 (Fed. Cir. 1986) (“This court
5
has cautioned against limiting the claimed invention to preferred embodiments or specific
6
examples in the specification.”). “To avoid importing limitations from the specification
7
into the claims, it is important to keep in mind that the purposes of the specification are to
8
teach and enable those of skill in the art to make and use the invention and to provide a
9
best mode for doing so.” Phillips, 415 F.3d at 1323.
15
One of the best ways to teach a person of ordinary skill in the art how to
make and use the invention is to provide an example of how to practice the
invention in a particular case. Much of the time, upon reading the
specification in that context, it will become clear whether the patentee is
setting out specific examples of the invention to accomplish those goals, or
whether the patentee instead intends for the claims and the embodiments in
the specification to be strictly coextensive. The manner in which the
patentee uses a term within the specification and claims usually will make
the distinction apparent.
16
Id. (internal citations omitted). Although “there is sometimes a fine line between reading
17
a claim in light of the specification, and reading a limitation into the claim from the
18
specification,” Comark Commc’ns, 156 F.3d at 1187, the Court believes that GoDaddy is
19
pursuing the latter rather than the former. Figure 8 does not establish the patentee’s “clear
20
disavowal” of “indication” to the narrower meaning of “confirmation.” See Thorner, 669
21
F.3d at 1365 (quoting Teleflex, 299 F.3d at 1325).
10
11
12
13
14
22
In short, notwithstanding the internal flaws within GoDaddy’s proposal, the Court
23
finds that if it were to construe “indication” as “confirmation,” a limitation from the
24
specification would be read into the claim. By focusing solely on the specification,
25
GoDaddy improperly seeks to construe the claims as limited to a single embodiment,
26
which goes against bedrock claim construction principles. See Comark Commc’ns, 156
27
F.3d at 1187.
28
- 43 -
1
Nonetheless, the patentee did not merely claim “indication” as a nebulous
2
indication without concern of later verification. The intrinsic record conveys that the
3
primary purpose of the invention is to provide information regarding the delivery,
4
opening, and content of an electronic message that can be “verified.” For example, Claim
5
1 of the ‘104 Patent states that the “indication of the opening of the message at the
6
recipient” is “includ[ed]” in the “authenticatible information” which is sent to the sender.
7
‘104 Patent col. 28 ll. 10–13; see also ‘198 Patent col. 28 ll. 20–22 (“providing an
8
authenticatible information related to the message, including the indication of the
9
delivery of the message at the recipient, at the server . . . .”). As construed below,
10
“authenticatible information” is certain information that “can be verified.” Accordingly,
11
because the “indication of the opening of the message” is an element of “authenticatible
12
information,” the indication itself must be verifiable.
13
14
15
For these reasons, the Court construes “indication” as “verifiable information that
indicates.”
b.
“opened”
16
The parties also dispute the meaning of the term “opened” as used by the asserted
17
claims. RPost argues that “opened” does not need to be construed because the words
18
“opened,” “viewed,” and “read” all embody different meanings and the inventor claimed
19
“opened.” (Doc. 119 at 6). In response, GoDaddy defines “opened” as “viewed” because,
20
according to the specification, “the message is opened for reading,” and it would be
21
impossible to read a message without at some point viewing it. (Doc. 117 at 10).
22
The Court finds that “opened” does not require further construction. In construing
23
claim terms, the Court need not clarify a term if it has a plain meaning that requires no
24
clarification. See U.S. Surgical, 103 F.3d at 1568. Here, “opened” is a generic term that is
25
readily understood within the context of the claims to connote that a message was
26
“opened” by the recipient. A jury will have no trouble understanding this concept and
27
GoDaddy has not raised an actual dispute as to the scope of the term. It would be illogical
28
for the Court to force the jury to consider convoluted semantics of whether the message
- 44 -
1
was “opened,” “viewed,” or “read” when the patentee already claimed the generic term
2
“opened.” Thus, this portion of GoDaddy’s proposal is rejected.
c.
3
“message”
4
The parties’ final dispute is whether “message” should be interpreted as
5
“message” or “message content.” GoDaddy proposes “message content” but does not
6
explain why such a construction is necessary. See (Doc. 117 at 9–10). In the absence of
7
compelling evidence to the contrary, the Court elects not to construe this portion of the
8
phrase. “Message” is a readily understandable term and GoDaddy has not brought to the
9
Court’s attention a valid dispute concerning the term’s scope. Moreover, because the
10
Court declined to define “opened” as “viewed,” construing this phrase as “opened the
11
message content” makes little sense. The Court therefore rejects this portion of
12
GoDaddy’s proposal.
4.
13
Conclusion
14
For these reasons, the Court construes “an indication that the message has been
15
opened by (delivered to) a recipient” as “verifiable information that indicates that the
16
message has been opened by (opened at; delivered to) the recipient.”8
17
E.
18
1.
19
20
21
22
23
The Parties’ Positions
As with Term No. 4, the parties’ dispute centers on the term “indication.” RPost
proposes a construction of “information that indicates that the message has been received
by the recipient (recipient processor).” (Doc. 191-1 at 1–2). GoDaddy responds by
proposing: “confirmation that the message content was received by the recipient.” (Id.)
2.
24
25
“an indication of receipt of the message by the recipient (recipient
processor)” (Term No. 5)
Analysis
This phrase is used in the asserted claims of the ‘389 Patent as follows:
26
27
28
8
The Court includes “opened at” in its construction because Claim 18 of the ‘198
Patent claims “opened at the recipient.” See ‘198 Patent col. 29 ll. 23.
- 45 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
1. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
...
receiving at the server from the recipient an indication of the receipt
of the message by the recipient;
forming at the server a first information from the at least a portion of
the mail transport protocol dialog and the indication of the receipt of the
message by the recipient . . . .
‘389 Patent col. 27 ll. 58–col 28 ll. 3 (emphasis added).
7. A system for transmitting a message through an electronic mail
system from an originating processor to a recipient processor and providing
proof of receipt of the message by the recipient process, comprising:
a server displaced from the originating processor, the server capable
of being configured by software commands to:
...
receive an indication of receipt of the message from the recipient
processor and a mail transport protocol dialog generated by the electronic
mail system during transmission of the message from the server to the
recipient processor;
generate a first information including the indication of receipt of the
message from the recipient processor and at least a portion of the mail
transport protocol dialog generated by the electronic mail system during
transmission of the message from the server to the recipient processor.
Id. col. 28 ll. 33–52 (emphasis added).
14. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
...
receiving at the server from the recipient a first information
including an indication of the receipt of the message by the recipient and at
least a portion of a mail transport protocol dialog generated during
transmission of the first information from the server to the recipient . . . .
Id. col. 29 ll. 17–col. 30 ll. 5.
27
28
- 46 -
1
The Court adopts its analysis for the terms “indication” and “message” as set forth
2
for Term No. 4 and therefore construes this phrase as “verifiable information that
3
indicates that the message was received by the recipient (recipient processor).”
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
F.
“an indication of the failure to deliver the message to the recipient”
(Term No. 6)
1.
The Parties’ Positions
RPost proposes a construction of “information that indicates that the message has
failed to be delivered to the recipient.” (Doc. 191-1 at 2). GoDaddy responds that the
phrase should be defined as “confirmation that the message content was not received by
the recipient.” (Id.)
2.
Analysis
This phrase is found in the asserted claims of the ‘199 Patent as follows:
1. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
...
receiving at the server from the recipient an indication of the failure
to deliver the message to the recipient;
forming at the server a first information from the at least a portion of
the data transport protocol dialog and the indication of the failure to deliver
the message by the recipient . . . .
‘199 Patent col. 27 ll. 58–65 (emphasis added).
The parties again dispute the claim terms “indication” and “message.” The Court
adopts its analysis as set forth in Term No. 4 and construes “indication” as “verifiable
information that indicates” and does not construe “message.”
The parties also proffer different constructions for the balance of the phrase.
GoDaddy suggests a construction that interprets “failure to deliver” as “not receiv[ing]”
the message. (Doc. 191-1 at 2). However, the ‘199 Patent does not speak in terms of
“receipt” of the message but claims whether the message failed to be “delivered.” The
27
28
- 47 -
1
Court finds that this portion of the claim uses plain language the jury will readily be able
2
to understand without further construction.
3
4
The Court therefore construes Term No. 6 as “verifiable information that indicates
the failure to deliver the message to the recipient.”
6
“executing the link when the message is opened at the recipient to
control the server to provide an indication that the message has been
opened at the recipient” (Term No. 7)
7
1.
5
G.
The Parties’ Positions
8
RPost proposes a construction that closely tracks the claim language: “executing
9
the link when the message is opened at the recipient to cause the server to provide an
10
indication that the message has been opened at the recipient.” (Doc. 191-1 at 2).
11
GoDaddy responds by construing the phrase as: “action by the recipient when the
12
message is opened at the recipient to control the server to provide proof that the message
13
has been opened at the recipient, the proof providing a legal or other evidentiary status on
14
par with, if not superior to, that of registered United States mail.” (Id.) GoDaddy argues
15
that the “structure” of the asserted claims “makes clear that—once the message is opened
16
at the recipient—it is the recipient (including the link at the recipient) that controls the
17
server to provide the attendant proof that the message has been opened at the recipient.”
18
(Doc. 117 at 11). GoDaddy also maintains that the “core purpose of the claimed
19
inventions is to provide not merely an ‘indication,’ but ‘proof regarding the delivery and
20
contents of an e-mail message.’” (Id. at 11–12). GoDaddy finally argues that RPost’s
21
proposed change from “control” to “cause” is flawed because the two words are not
22
synonymous. (Id. at 12).
23
RPost criticizes GoDaddy’s construction for three reasons. First, RPost argues that
24
GoDaddy’s proposal improperly limits the claim to actions performed by the recipient.
25
(Doc. 114 at 10). RPost explains that the link is executed “at the recipient,” not “by the
26
recipient” as GoDaddy contends. (Doc. 119 at 6). Second, RPost asserts that GoDaddy’s
27
construction impermissibly narrows the claim’s plain meaning by construing “indication”
28
- 48 -
1
as “proof.” (Doc. 114 at 10). Third, RPost insists that GoDaddy’s proposed limitation
2
regarding “legal or other evidentiary status” is not supported by the claim language and
3
violates the intrinsic record. (Id. at 10–11).
4
2.
Analysis
5
This phrase is used in Claim 1 of the ‘104 Patent as follows:
6
1. A method of transmitting a message from a sender to a recipient
and providing an indication that the message was opened by the recipient,
comprising:
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
adding a link to the message by the server, the link configured to
execute when the message is opened at the recipient to provide an
indication that the message has been opened by the recipient,
...
executing the link when the message is opened at the recipient to
control the server to provide an indication that the message has been
opened at the recipient . . . .
‘104 Patent col. 27 ll. 63–col. 28 ll. 9 (emphasis added). The Court will analyze the
parties’ proposals in turn.
a.
“control”
The Court first reviews RPost’s suggestion that “control” should be interpreted as
“cause.” GoDaddy complains that such a construction is improper because the two words
have different meanings. (Doc. 117 at 12). To support its argument, GoDaddy cites to the
American Heritage Dictionary which defines “control” as “[t]o exercise authoritative or
dominating influence over; direct” and “cause” as “1a. The producer of an effect, result,
or consequence. b. The one, such as a person, event, or condition, that is responsible for
an action or result.” (Id.)
It is apparent from the dictionary definitions that the two terms have entirely
different meanings. While “cause” simply refers to one that is responsible for an action or
result, “control” requires that one exercise some sort of dominion or authority over
another. In other words, “cause” is broader than “control.” This distinction is exemplified
by the ‘198 Patent’s usage of the two words in an unrelated claim. See ‘198 Patent col. 29
- 49 -
1
ll. 1–4 (“16. The method of claim 15, wherein activating the link also causes information
2
to be displayed to the recipient and to control the server to make a record of the
3
information displayed.” (emphasis added)). RPost does not point to evidence within the
4
intrinsic record to show that the inventor intended to claim “control” with a broader
5
meaning. Accordingly, this portion of RPost’s proposed construction is rejected.
b.
6
“executing the link”
7
The Court next reviews GoDaddy’s proposal that “executing the link” should be
8
construed as “action by the recipient.” GoDaddy explains that the “structure” of the
9
asserted claims “makes clear that—once the message is opened at the recipient—it is the
10
recipient (including the link at the recipient) that controls the server to provide the
11
attendant proof that the message has been opened at the recipient.” (Doc. 117 at 11).
12
GoDaddy further notes that “it is . . . the recipient (i.e., the link in the message) that
13
performs the claimed function.” (Id.) RPost replies that even though the recipient
14
performs the opening of the message, that fact is irrelevant because “the disputed claim
15
function is executing, which the link does on its own.” (Doc. 119 at 6).
16
The Court finds that “executing the link” does not require the recipient to
17
affirmatively act beyond opening the message. Rather, the function of the claim,
18
“executing,” occurs by the link itself “when the message is opened.” Furthermore,
19
GoDaddy’s likening of the “recipient” to the “link” itself is baseless, as the two terms are
20
clearly distinct. Consequently, this portion of GoDaddy’s proposal is rejected.
21
The Court adopts a slightly amended version of this portion of RPost’s proposal:
22
“the link executing on its own when the message is opened at the recipient.” This
23
construction clarifies for the jury that the link executes on its own when the message is
24
opened.
25
c.
“an indication”
26
Finally, the Court examines GoDaddy’s argument that “an indication” should be
27
interpreted as “proof that the message has been opened at the recipient, the proof
28
providing a legal or other evidentiary status on par with, if not superior to, that of
- 50 -
1
registered United States mail.” (Doc. 191-1 at 2).9 While it is undisputed that the claim
2
language does not include this purported “evidentiary” limitation, GoDaddy argues that
3
the limitation emerges from the specification and is essential to differentiate the Tomkow
4
Patents from prior art. See (Doc. 117 at 11–12).
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
The portion of the shared specification from which GoDaddy plucks this limitation
is found in the Summary of the Present Invention which reads as follows:
A general object of the present invention is to provide a system and
method for reliably verifying via secure and tamper-proof documentation
the content and delivery of an electronic message such as an e-mail. Ideally,
the invention will give e-mail and other electronic messages a legal status
on par with, if not superior to, that of registered United States mail.
However, it is not necessary to the invention that any particular legal status
is accorded to messages sent according to the methods taught herein, as the
invention provides useful information and verification regardless.
‘199 Patent col. 3 ll. 8–17; ‘389 Patent col. 3 ll. 6–15 (same); ‘104 Patent col. 3 ll. 6–15
(same); ‘198 Patent col. 3 ll. 9–18 (same); ‘913 Patent col. 3 ll. 8–17 (same). Based on
this language and references to prior art in the specification, GoDaddy maintains that the
“indication” provided by the invention must have some level of evidentiary status—legal
or otherwise—that is equal or superior to registered United States mail. (Doc. 117 at 11).
To begin, as the Court has already recounted, construing this term must be done in
light of the Federal Circuit’s frequent admonition against reading limitations from the
specification into the claim. See Comark Commc’ns, 156 F.3d at 1187. In ascertaining
whether the patentee disavowed the full scope of a claim, the Court must refrain from
committing the “cardinal sin” of reading limitations from the specification into the
claims. Teleflex, 299 F.3d at 1326 (citing Comark Commc’ns, 156 F.3d at 1186). The
only way a specification may narrow the scope of a disputed claim term is if the patentee
“demonstrate[d] intent to deviate from the ordinary and accustomed meaning of a claim
25
26
27
28
9
GoDaddy proposes this or a similar limitation for a dozen disputed claim terms
in the Tomkow Patents. See (Docs. 117, 191-1 (proposing this limitation for Term Nos. 7,
8, 9, 10, 11, 13, 14, 15, 16, 17, 23, and 24).
- 51 -
1
term by including in the specification expressions of manifest exclusion or restriction,
2
representing a clear disavowal of claim scope.” Thorner, 669 F.3d at 1365 (quoting
3
Teleflex, 299 F.3d at 1325). Here, because the proposed evidentiary limitation
4
purportedly springs from the specification, GoDaddy must show that the inventor clearly
5
disavowed the claim scope.
6
In this regard, the Court is not persuaded that GoDaddy’s proposed evidentiary
7
limitation exists. The specification flatly expresses that “it is not necessary to the
8
invention that any particular legal status is accorded to messages sent according to the
9
methods taught herein, as the invention provides useful information and verification
10
regardless.” GoDaddy nonetheless attempts to circumvent this language by arguing that
11
its proposal affords two methods of attaining the evidentiary status of registered United
12
States mail: (1) “legal” or (2) “other evidentiary status.” As the inventor clearly disclosed
13
that no “legal” status was required for the invention, the question becomes whether an
14
“indication” must have an “evidentiary status on par with, if not superior to, that of
15
registered United States mail.”
16
In response to this question, the Court finds that GoDaddy’s proposal misses the
17
mark. As discussed at length for Term No. 4, the “indication” provided by the invention
18
is not the “proof” that is discussed in the specification. The second step of the process—
19
the “verification” of a message—is when the invention arguably provides “proof” of
20
certain aspects of the message. Consequently, even if the Court were to sidestep the
21
“cardinal sin” of reading limitations from the specification into a claim and disregard the
22
invention’s express disclaimer that no legal status is vital to the invention, the Court
23
would still reject this portion of GoDaddy’s argument because the purported evidentiary
24
limitation does not even concern the invention’s initial step of providing an “indication.”
25
26
Accordingly, the Court adopts its construction of “indication” as explained in
Term No. 4.
27
28
- 52 -
3.
1
Conclusion
2
For these reasons, the Court construes this phrase as: “the link executing on its
3
own when the message is opened at the recipient to control the server to provide
4
verifiable information that indicates that the message has been opened at the recipient.”
7
“the link being configured to execute automatically when the message
is opened at the recipient processor to control the server to provide an
indication at the server that the message has been opened at the
recipient processor” (Term No. 8)
8
1.
5
6
H.
The Parties’ Positions
9
Similar to its proposed construction for Term No. 7, RPost advances the following
10
construction of Term No. 8: “the link programmed to execute automatically when the
11
message is opened at the recipient to cause the server to provide an indication at the
12
server that the message has been opened at the recipient.” (Doc. 191-1 at 2). As seen,
13
RPost modifies the claim language in two ways: (1) defining “control” as “cause” and (2)
14
construing “configured” as “programmed.” RPost asserts that the minor linguistic change
15
from “configured” to “programmed” clarifies for the jury that the term is “used in a
16
computer programming sense.” (Doc. 119 at 10).
17
In response, GoDaddy proposes a construction of: “[link configured to execute
18
through] action by the recipient when the message is opened at the recipient to control the
19
server to provide proof that the message has been opened at the recipient, the proof
20
providing a legal or other evidentiary status on par with, if not superior to, that of
21
registered United States mail.” (Doc. 191-1 at 2).
22
2.
Analysis
23
This phrase is used in Claim 27 of the ‘104 Patent as follows:
24
27. A system for transmitting a message from an originating
processor to a recipient processor in an electronic mail system and
providing an indication that the message was opened by the recipient
processor, comprising:
25
26
27
28
a server in electronic communication in the electronic mail system,
the server receiving the message from the originating processor and adding
a link to the message before transmitting the message and link to the
- 53 -
1
2
3
4
recipient processor, the link being configured to execute automatically
when the message is opened at the recipient processor to control the server
to provide an indication at the server that the message has been opened at
the recipient processor . . . .
‘104 Patent col. 31 ll. 20–32 (emphasis added).
5
For the reasons set forth in Term No. 7, the Court rejects GoDaddy’s evidentiary
6
proposal and its suggestion that the claim requires “action by the recipient.” Likewise, the
7
Court also rejects the portion of RPost’s proposal that construes “control” as “cause.”
8
As to RPost’s argument that “configured” should be defined as “programmed,” the
9
Court finds that such a construction is unwarranted. The term “configured” has a plain
10
and ordinary meaning that the jury will be able to understand within the context of this
11
electronic messaging dispute. See U.S. Surgical, 103 F.3d at 1568. RPost has not shown
12
that the term is used in a manner that diverges from its plain meaning, and therefore the
13
Court rejects this portion of RPost’s proposal.
14
For these reasons, the Court construes this phrase as: “the link being configured to
15
execute automatically when the message is opened at the recipient to control the server to
16
provide verifiable information that indicates at the server that the message has been
17
opened at the recipient processor.”
19
“the link configured to execute when the link is activated at the
recipient to provide an indication that the message has been opened by
(delivered to) a recipient” (Term No. 9)
20
1.
18
I.
The Parties’ Positions
21
Similar to its proposals for Term Nos. 7 and 8, RPost suggests that this phrase
22
should be interpreted as “the link programmed to execute when the link is activated at the
23
recipient to provide an indication that the message has been opened by (delivered to) a
24
recipient.” (Doc. 191-1 at 3).
25
In response, GoDaddy argues that the claim should be construed as “[link
26
configured to execute through] action by the recipient when the message is opened at the
27
recipient to control the server to provide proof that the message has been opened at the
28
- 54 -
1
recipient, the proof providing a legal or other evidentiary status on par with, if not
2
superior to, that of registered United States mail.” (Id.)
3
2.
Analysis
4
This phrase is found in Claims 1, 18, and 32 of the ‘198 Patent as follows:
5
1. A method of transmitting a message from a sender to a recipient
and providing an indication that the message was opened by the recipient,
comprising:
6
7
8
9
10
11
12
13
14
15
16
17
associating a link with the message by the server, the link configured
to execute when the link is activated at the recipient to provide an
indication that the message has been opened by a recipient . . . .
‘198 Patent col. 28 ll. 6–14 (emphasis added).
18. A system transmitting a message from a sender to a recipient and
providing an indication that the message was opened by the recipient,
comprising:
a server in electronic communication with the sender and the
receiver, the server programmed to receive a message from the sender, to
associate a link with the message, the link configured to execute when the
link is activated at the recipient to provide an indication that the message
has been opened by a recipient, to transmit the message and the link from
the server to the recipient . . . .
Id. col. 29 ll. 11–20 (emphasis added); see id. col. 30 ll. 7–16 (same).
18
For the reasons set forth in Term No. 7, the Court rejects GoDaddy’s evidentiary
19
proposal and its suggestion that the claim requires “action by the recipient.” For the
20
reasons expressed in Term No. 8, the Court also rejects the portion of RPost’s proposal
21
that construes “configured” as “programmed.”
22
The remaining dispute is whether “activated” should be construed as “opened at
23
the recipient to control the server.” The use of the term “activated” in the ‘198 Patent is
24
different than the prior two disputed terms from the ‘104 Patent which claim “opened at
25
the recipient.” “Activated” is a readily-understandable term, and there is no evidence
26
before the Court showing that the inventor of the ‘198 Patent intended the link to be
27
activated only when the message is opened. While it could be argued that because the
28
activation of the link causes an indication of the opening of the message to be sent to the
- 55 -
1
recipient it is the opening of the message that activates the link, this is not necessarily
2
true. In fact, the dependent claims of Claim 1 suggest other ways of activating the link.
3
See ‘198 Patent col. 28 ll. 26–27. Thus, the Court rejects GoDaddy’s proposal and does
4
not construe the generic term “activated.”
5
For these reasons, the Court defines Term No. 9 as “the link configured to execute
6
when the link is activated at the recipient to provide verifiable information that indicates
7
that the message has been opened by (delivered to) the recipient.”
8
9
10
J.
“executing the link when the link is activated at the recipient to control
the server to provide an indication that the message has been delivered
to the recipient” (Term No. 10)
1.
The Parties’ Positions
11
For Term No. 10, RPost asks the Court to adopt the following construction:
12
“executing the link when the link is called at the recipient to cause the server to provide
13
an indication that the message has been delivered to the recipient.” (Doc. 191-1 at 3–4).
14
In response, GoDaddy proposes a construction of “[executing the link through]
15
action by the recipient when the message is opened at the recipient to control the server to
16
provide proof that the message has been opened at the recipient, the proof providing a
17
legal or other evidentiary status on par with, if not superior to, that of registered United
18
States mail.” (Id.)
19
2.
Analysis
20
This phrase is used in Claim 1 of the ‘198 Patent as follows:
21
1. A method of transmitting a message from a sender to a recipient
and providing an indication that the message was opened by the recipient,
comprising:
22
23
24
25
26
27
...
executing the link when the message is activated at the recipient to
control the server to provide an indication that the message has been
delivered to the recipient . . . .
‘198 Patent col. 28 ll. 6–19 (emphasis added).
28
- 56 -
1
Several of the modifications proposed by the parties have already been resolved in
2
prior terms. As to GoDaddy’s “evidentiary” and “action by the recipient” proposals, the
3
Court adopts its reasoning for Term No. 7. Regarding GoDaddy’s construction of the
4
claim term “activated,” the Court adopts its analysis as set forth for Term No. 9. Finally,
5
the Court adopts its reasoning and rejection of RPost’s construction of “control” as
6
explained in Term No. 7.
7
RPost additionally proposes that the term “activated” should be interpreted as
8
“called.” RPost does not explain this construction in its briefing, and the Court is not
9
persuaded that construction of this term is necessary for the reasons set forth in Term
10
No. 9. Thus, the Court rejects this portion of RPost’s proposal.
11
For these reasons, the Court construes Term No. 10 as “the link executing on its
12
own when the link is activated at the recipient to control the server to provide verifiable
13
information that indicates that the message has been delivered to the recipient.”
15
“wherein the link is executed when the link is activated at the recipient
to control the server to provide an indication that the message has been
opened at (delivered to) the recipient” (Term No. 11)
16
1.
14
K.
The Parties’ Positions
17
RPost argues that Term No. 11 should be construed as “wherein the link executed
18
when the link is called at the recipient to cause the server to provide an indication that the
19
message has been opened at (delivered to) to the recipient.” (Doc. 191-1 at 4).
20
In response, GoDaddy proposes a construction of “[executing the link through]
21
action by the recipient when the message is opened at the recipient to control the server to
22
provide proof that the message has been opened at the recipient, the proof providing a
23
legal or other evidentiary status on par with, if not superior to, that of registered United
24
States mail.” (Id.)
25
26
2.
Analysis
This phrase is found in the ‘198 Patent as follows:
27
28
- 57 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
18. A system transmitting a message from a sender to a recipient and
providing an indication that the message was opened by the recipient,
comprising:
a server in electronic communication with the sender and the
receiver, the sever programmed to receive a message from the sender, to
associate a link with the message, the link configured to execute when the
link is activated at the recipient to provide an indication that the message
has been opened by a recipient, to transmit the message and the link from
the server to the recipient, wherein
the link is executed when the link is activated at the recipient to
control the server to provide an indication that the message has been
opened at the recipient . . . .
‘198 Patent col. 29 ll. 11–24 (emphasis added). Asserted Claim 32 incorporates the same
language as Claim 18, but replaces “delivered to” with “opened at.” Id. col. 30 ll. 7–20.
The Court has already settled all of the parties’ disputes for prior terms and
incorporates those analyses and constructions here. The Court therefore defines this
phrase as “wherein the link is executed when the link is activated at the recipient to
control the server to provide verifiable information that indicates that the message has
been opened at (delivered to) the recipient.”
L.
“authenticatible information” (Term No. 12)
1.
The Parties’ Positions
RPost proposes that “authenticatible information” should be broadly construed as
“information regarding the content or delivery of a message that can be verified.”
(Doc. 191-1 at 4–5). RPost argues this construction is “consistent with the intrinsic
record, which repeatedly refers to authentication in the context of verifying the content
and delivery of an electronic message.” (Doc. 114 at 11).
GoDaddy, on the other hand, proposes the following itemized construction:
“information unique to the message, the digital signature of the message, and the portion
of the mail transport dialog generated during transmission of the message.” (Doc. 191-1
at 4–5). GoDaddy contends that its construction is grounded in the specification’s
disclosure of “digital signature.” (Doc. 117 at 13). Specifically, GoDaddy explains that
- 58 -
1
“authenticatible information” must include the message’s digital signature, which it
2
defines as a “digital code that uniquely identifies the message and/or its attachments.”
3
(Id.)10 GoDaddy did not clarify in its briefing or during the Markman Hearing why the
4
balance of its proposal, “the portion of the mail transport dialog generated during
5
transmission of the message,” is necessary.
6
RPost replies that GoDaddy’s proposal is problematic because GoDaddy did not
7
cite any portion of the intrinsic record showing that the inventor intended to limit
8
“authenticatible information” to three enumerated elements. (Doc. 119 at 7). RPost also
9
points out that the term “digital signature” is not claimed in either the ‘104 or ‘198
10
Patents where “authenticatible information” is claimed. (Id.) RPost thus contends that
11
GoDaddy is attempting to limit “authenticatible information” by terms from the
12
specification. (Doc. 114 at 11).
13
2.
14
15
16
17
The term “authenticatible information” is used by the ‘104 and ‘198 Patents. The
‘104 Patent claims as follows:
1. A method of transmitting a message from a sender to a recipient
and providing an indication that the message was opened by the recipient,
comprising:
18
19
20
21
Analysis
...
providing an authenticatible information related to the message,
including the indication of the opening of the message at the recipient, at
the server, and
22
transmitting the indication of the opening of the message at the
recipient, and the authenticatible information from the server to the sender.
23
‘104 Patent col. 27 ll. 63–col. 28 ll. 16 (emphasis added). The term is also claimed by the
24
‘198 Patent as follows:
25
26
27
28
10
As GoDaddy notes, RMail defined “digital signature” in this manner before
Judge Gilstrap. See RMail, 2013 WL 968246, at *55. However, “digital signature” is not
claimed by either of the asserted claims here, nor does GoDaddy suggest that this
definition should be included in the construction.
- 59 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1. A method of transmitting a message from a sender to a recipient
and providing an indication that the message was opened by the recipient,
comprising:
...
providing an authenticatible information related to the message,
including the indication of the delivery of the message at the recipient, at
the server, and
transmitting the indication of the delivery of the message at the
recipient, and the authenticatible information from the server to the sender.
‘198 Patent col. 28. ll. 6–25 (emphasis added).
18. A system transmitting a message from a sender to a recipient and
providing an indication that the message was opened at the recipient,
comprising:
...
wherein the server is programmed to form an authenticatible
information related to the message, and to transmit the indication of the
opening of the message at the recipient and the authenticatible information
from the server to the sender.
Id. col. 29 ll. 11–28 (emphasis added); see id. col. 30 ll. 7–25 (same).
16
GoDaddy argues that “digital signature” should be included within the
17
construction of “authenticatible information.” The term “digital signature” is disclosed in
18
the specification as follows:
19
20
21
22
23
24
25
26
27
The present invention includes an electronic message system that
creates and records a digital signature of each electronic message sent
through the system. An originator may send a copy of the electronic
message to the system or generate the electronic message within the system
itself. The system then forwards and delivers the electronic message to all
recipients (or to the designated message handlers associated with the
recipients), including “to” addressees and “cc” addressees. Thereafter, the
system returns a receipt of delivery to the originator of the electronic
message. The receipt includes, among other things: the original message,
the digital signature of the message, and a handshaking and delivery
history including times of delivery to the recipients. To later verify and
authenticate information contained in the receipt, the originator or user
sends a copy of the receipt to the system. The system then verifies that the
digital signature matches the original message and the rest of the receipt. If
28
- 60 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
the two match, then the system sends a letter or provides other confirmation
of authenticity verifying that the electronic message has not been altered.
Id. col. 3 ll. 19–38 (emphasis added).
At the outset, the Court agrees with GoDaddy’s argument that the information
comprising “authenticatible information” must be “unique” to a particular message. If the
information was not unique to a message, verification of the message would be infeasible
thereby making the claims limitless. GoDaddy’s proposed construction, however, is
superfluous. Specifically, GoDaddy defines “digital signature” as a “digital code that
uniquely identifies the message and/or its contents.” (Doc. 117 at 13 (emphasis added)).
GoDaddy then offers a construction that includes both “information unique to the
message” and “the digital signature of the message.” There is no need to use both phrases
in the construction when the phrases purportedly mean the same thing. On balance, the
Court finds that “unique” would be more helpful to the jury than “digital signature”—a
term that is not in the claim language and that would require a separate definition.
GoDaddy also contends that authenticatible information must include “the portion
of the mail transport dialog generated during transmission of the message.” (Doc. 191-1
at 4–5). GoDaddy does not explain why this limitation is necessary, and the Court does
not find it to be supported by the intrinsic record. In fact, the ‘104 and ‘198 Patents do not
even recite the term “mail transport dialog.” Thus, if the Court were to adopt this portion
of GoDaddy’s construction, it would be importing concepts from other Tomkow Patents
into the ‘104 and ‘198 Patents.
Finally, the Court agrees with RPost that “authenticatible information” is
information regarding either the “content or delivery” of a message that “can be verified.”
The information must be able to be verified due to the two-step verification process as
explained in Term No. 4.
For these reasons, the Court adopts the following amalgam of the parties’
proffered constructions for “authenticatible information”: “information unique to the
content or delivery of a message that can be verified.”
- 61 -
1
2
M.
“mail transport protocol dialog” (Term No. 13)
1.
The Parties’ Positions
3
RPost contends that Term No. 13 should be interpreted as “mail transport data
4
including a sequence of at least one command and at least one response.” (Doc. 191-1 at
5
5). RPost posits that this construction is “virtually identical” to Judge Gilstrap’s
6
construction of the same term. (Doc. 114 at 12).
7
In response, GoDaddy proposes a narrower definition: “a list of commands and
8
responses exchanged between servers during transmission of the message that is
9
sufficient to prove delivery of the message to the recipient, providing a legal or other
10
evidentiary status on par with, if not superior to, that of registered United States mail.”
11
(Doc. 191-1 at 5). GoDaddy explains that its proposal “make[s] clear that the commands
12
and responses exchanged during transmission of the message must be sufficient to prove
13
delivery of the message to the recipient.” (Doc. 117 at 14). GoDaddy further argues that
14
the inclusion of the phrase “or other evidentiary status” in its construction overcomes
15
RPost’s argument that the invention need not confer a legal status upon its messages. (Id.)
16
RPost complains that GoDaddy’s proposal is “completely at odds with the
17
intrinsic record, which expressly states that it is not necessary to the invention that
18
messages be accorded legal status.” (Doc. 114 at 12). RPost also contends that
19
GoDaddy’s proposal conflicts with Judge Gilstrap’s definition of “dialog” and
20
improperly imports limitations from the specification into the claim. (Id.; Doc. 119 at 7).
21
2.
Analysis
22
The term “mail transport protocol dialog” is used in the ‘389 Patent as follows:
23
1. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
24
25
26
27
...
receiving at the server at least a portion of a mail transport protocol
dialog generated during transmission of the message from the server to the
recipient . . .
28
- 62 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
forming at the server a first information that the at least a portion of
the mail transport protocol dialog and the indication of the receipt of the
message by the recipient . . .
‘389 Patent col. 27 ll. 58–col. 28 ll. 3 (emphasis added).
7. A system for transmitting a message through an electronic mail
system from an originating processor to a recipient processor and providing
proof of receipt of the message by the recipient process, comprising:
...
receive an indication of receipt of the message from the recipient
processor and a mail transport protocol dialog generated by the electronic
mail system during transmission of the message from the server to the
recipient processor;
generate a first information including the indication of receipt of the
message from the recipient processor and at least a portion of the mail
transport protocol dialog generated by the electronic mail system during
transmission of the message from the server to the recipient processor.
Id. col. 28 ll. 33–52 (emphasis added).
14. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
receiving at the server from the recipient a first information
including an indication of the receipt of the message by the recipient and at
least a portion of a mail transport protocol dialog generated during
transmission of the first information from the server to the recipient . . . .
Id. col. 29 ll. 16–col. 30 ll. 5 (emphasis added).
20
As used in the ‘372 and ‘557 Patents, Judge Gilstrap construed “mail transport
21
protocol dialog” as: “data including a list of at least one command and at least one
22
response exchanged between devices during the transmission of a message.” RMail, 2013
23
WL 968246, at *55. In doing so, Judge Gilstrap relied upon the patents’ specification and
24
prosecution history. Id. Specifically, Judge Gilstrap considered the following excerpt
25
from the ‘372 Patent’s specification:
26
27
28
Whether the connection is SMTP or ESMTP, the RPost server will record
the entire protocol dialogue between the two servers. Typically this
dialogue will include protocol messages in which, among other things, the
destination server identifies itself, grants permission to upload a message
- 63 -
1
3
for a named recipient, and acknowledges that the message was received.
RPost will save the record of this transaction in such way that it may be
later retrieved and included in or attached to the RPost Delivery Receipt for
this message.
4
Id. at *54. The ‘389 Patent shares this portion of the specification. See ‘389 Patent col. 12
5
ll. 65–col. 13 ll. 6.
2
6
Judge Gilstrap further explained that during prosecution of the patent, the inventor
7
disclaimed that “a dialog, as that term is understood by one skilled in the relevant art, is a
8
list of commands and responses exchanged between an outgoing server and a destination
9
address or server to transmit a message.” RMail, 2013 WL 968246, at *54. Judge Gilstrap
10
concluded that this statement rose “to the level of a ‘reasonably clear’ lexicography
11
defining ‘dialog’ in the context of ‘mail transport dialog’ as being data that includes a list
12
of command and responses exchanged during transmission of a message.” Id. (citations
13
omitted).
14
The ‘389 Patent describes two primary mail transport protocols: SMTP and
15
ESMTP. The ‘389 Patent describes an (E)SMTP “dialogue” between the sender’s Mail
16
Transport Agent (“MTA”) and the recipient’s MTA during which the message is
17
delivered. See, e.g., ‘389 Patent col. 11 ll. 50–56, col. 12 ll. 65–67. A person of ordinary
18
skill in the art would understand “at least a portion of a mail transport protocol dialogue”
19
to include information from the dialogue between the MTAs (e.g., an SMTP command or
20
an SMTP response), not merely information from the message itself. Moreover, the Court
21
agrees with Judge Gilstrap’s analysis and finds that the construction of this term should at
22
least incorporate “data including a sequence of at least one mail transport protocol
23
command and at least one mail transport protocol response exchanged between devices
24
during transmission of the message.”11
25
26
27
28
11
RPost’s “virtually identical” proposed construction did not include the phrase
“exchanged between devices during transmission of a message” from Judge Gilstrap’s
construction. See (Doc. 191-1 at 5). During the Markman Hearing, however, RPost
- 64 -
1
As has been the case for several terms, GoDaddy raises an issue regarding the use
2
of the invention. Specifically, GoDaddy insists that the data must be “sufficient to prove
3
delivery of the message to the recipient, providing a legal or other evidentiary status on
4
par with, if not superior to, that of registered United States mail.” (Doc. 117 at 14). As
5
discussed for the “indication” terms above, however, even disregarding the “cardinal sin”
6
of reading limitations from the specification into the claim, the Court finds no
7
requirement that the invention bestow upon its messages an evidentiary status on par with
8
or superior to registered United States mail.
9
For these reasons, the Court adopts RPost’s proposed construction with minor
10
changes. Term No. 13 means “data including at least one mail transport protocol
11
command and at least one mail transport protocol response exchanged between devices
12
during transmission of a message.”
15
“at least a portion of a mail transport protocol dialog (data transport
dialog) generated (by the electronic mail system) during transmission
of the message from the server to the recipient (processor)” (Term
No. 14)
16
1.
13
14
N.
The Parties’ Positions
17
RPost contends that this phrase does not require further construction beyond
18
construing “mail transport protocol dialog.” (Doc. 191-1 at 5). GoDaddy appears to
19
advance the same construction as it did for Term No. 13. See (Doc. 117 at 13).
20
21
22
2.
Analysis
This phrase is claimed in the ‘389 Patent as quoted in Term No. 13 and also in
Claim 1 of the ‘199 Patent. The ‘199 Patent claims:
23
24
25
26
27
28
argued that this phrase should be included in the construction. The Court finds this phrase
would help the jury understand the meaning of the disputed term.
Additionally, GoDaddy’s proposal substitutes “servers” for “devices.” The Court
finds that the claims’ plain language does not require transmissions between servers and
rejects this proposal.
- 65 -
1
2
1. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
...
receiving at the server at least a portion of a data transport protocol
dialog generated during transmission of the message from the server to the
recipient; and
...
forming at the server a first information from the at least a portion of
the data transport protocol dialog and the indication of the failure to deliver
the message by the recipient . . . .
‘199 Patent col. 27 ll. 58–col. 28 ll. 4 (emphasis added).
In 2014, Symantec Corporation filed a petition with the Patent Trial and Appeal
Board (“Board”) requesting inter partes review of several claims of the ‘372 Patent, of
which the ‘389 and ‘199 Patents are continuations. See Symantec Corp. v. RPost
Commc’ns Ltd., 2014 WL 3542162, at *1 (Patent Tr. & App. Bd. July 15, 2014). RPost,
as patent owner, filed a response. Id. One of the claims before the Board for construction
was “at least a portion of a mail transport protocol dialog.” Id. at *6–7. RPost proposed
Judge Gilstrap’s construction: “data including a list of at least one command and at least
one response exchanged between devices during the transmission of a message.” Id. at
*7. The Board rejected the conjunctive nature of RPost’s proposal and construed the
phrase as “at least one mail transport protocol command or at least one mail transport
protocol reply.” Id. (emphasis added).
Because the claim recites “at least a portion,” the Court rejects RPost’s proposal
that no construction is necessary because the jury could mistakenly conclude—as RPost
did before the Board—that at least one command and one response is needed. Instead, the
Court adopts the substance of the Board’s construction and interprets this phrase to mean
“data including at least one mail transport protocol command or at least one mail
transport protocol response exchanged between devices during transmission of the
message.”
- 66 -
1
2
O.
“SMTP and ESMTP protocol dialog” (Term No. 15)
1.
The Parties’ Positions
3
RPost advances a construction that closely mirrors its proposals for the preceding
4
dialog terms. Specifically, RPost argues that “SMTP and ESMTP protocol dialog” should
5
be construed as “SMTP or ESMTP data including a list of at least one command and at
6
least one response generated by the electronic mail system during transmission of the
7
message from the server to the recipient.” (Doc. 191-1 at 5–6).
8
GoDaddy proposes the same construction as it did for Term Nos. 13 and 14: “a list
9
of commands and responses exchanged between servers during transmission of the
10
message that is sufficient to prove delivery of the message to the recipient, providing a
11
legal or other evidentiary status on par with, if not superior to, that of registered United
12
States mail.” (Id.)
13
2.
Analysis
14
This phrase is claimed by the ‘913 Patent as follows:
15
1. A method of transmitting a message from a sender to a recipient
through a server acting as a Mail Transport Agent, including the steps at the
server of:
16
17
18
19
20
21
22
23
24
25
26
27
transmitting the message to the recipient’s Mail Transport Agent in a
protocol dialog selected from a group consisting of the selected one of the
SMTP and ESMTP protocols; and
recording at the server some portion of the selected one of the SMTP
and ESMTP protocol dialog between the server and the recipient through
the server including those portions of the selected one of the SMTP and
ESMTP protocol dialog between the server and the recipient in which the
receiving Mail Transport Agent accepts or declines delivery of the
transmitted message.
‘913 Patent col. 27 ll. 41–54 (emphasis added).
For the reasons expressed for Term No. 13, the Court finds that the majority of
RPost’s construction would assist the jury in understanding the concepts of this term.
Thus, the Court construes “SMTP and ESMTP protocol dialog” as “SMTP or ESMTP
28
- 67 -
1
data including a list of at least one protocol command and at least one protocol response
2
exchanged between devices during transmission of a message.”
3
4
5
6
P.
“data transport protocol dialog” (Term No. 16)
1.
The Parties’ Positions
For the final “dialog” term, RPost proposes a construction of “transport data
including a list of at least one command and at least one response.” (Doc. 191-1 at 6).
7
GoDaddy proffers the same construction as it did for Term Nos. 13, 14, and 15: “a
8
list of commands and responses exchanged between servers during transmission of the
9
message that is sufficient to prove delivery of the message to the recipient, providing a
10
legal or other evidentiary status on par with, if not superior to, that of registered United
11
States mail.” (Id.)
12
2.
Analysis
13
“Data transport protocol dialog” is used in Claim 1 of the ‘199 Patent as follows:
14
1. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
15
16
17
18
19
20
21
22
23
24
25
26
...
receiving at the server at least a portion of a data transport protocol
dialog generated during transmission of the message from the server to the
recipient; and
...
forming at the server a first information from the at least a portion of
the data transport protocol dialog and the indication of the failure to
deliver the message by the recipient . . . .
‘199 Patent col. 27 ll. 58–col. 28 ll. 4 (emphasis added).
For the reasons set forth in Term No. 13, the Court finds that the majority of
RPost’s construction would be helpful to the jury. Thus, the Court construes this term as:
“transport data including a list of at least one command and at least one response
exchanged between devices during transmission of a message.”
27
28
- 68 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Q.
“before the message is authenticated (any authentication of the
message) by the server” (Term No. 17)
1.
The Parties’ Positions
RPost contends that Term No. 17 should be construed as “before the content and
delivery of the message is proved (proving the content and delivery of the message) by
the server. The plain language of this phrase does not require that any authentication of
the message be performed by the server.” (Doc. 191-1 at 6–7). To support the latter part
of its construction, RPost notes that Judge Gilstrap came to a similar conclusion.
(Doc. 114 at 12–13).
GoDaddy agrees that this phrase requires providing proof of the content and
delivery of a message but contends that the construction should also include “how” and
“why” such proof is generated. (Doc. 117 at 14). Thus, GoDaddy proposes the following
construction: “before proving the content and delivery of the message by comparing and
matching authenticable information so as to provide a legal or other evidentiary status on
par with, if not superior to, that of registered United States mail.” (Id.)
RPost replies that GoDaddy’s proposal impermissibly imports limitations from the
specification into the claim. (Doc. 119 at 8).
2.
Analysis
This disputed phrase is found in several claims of the ‘389 Patent and Claim 1 of
the ‘199 Patent. The ‘389 Patent claims as follows:
1. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
...
transmitting, before any authentication of the message, a copy of the
message and the first information to the sender from the server.
‘389 Patent col. 27 ll. 58–col. 28 ll. 7 (emphasis added).
14. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
- 69 -
1
2
3
4
5
6
7
8
9
10
storing a representation of the message and the first information
received by the server from the recipient in a memory, before any
authentication of the message.
15. The method of claim 14, further comprising:
Transmitting the representation of the message and the first
information received by the server from the recipient to the sender from the
server, before any authentication of the message.
Id. col. 29 ll. 16–col. 30 ll. 13 (emphasis added). Similarly, the ‘199 Patent claims:
1. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
...
11
transmitting, before any authentication of the message, a copy of the
first information to the sender from the server.
12
‘199 Patent col. 27 ll. 58–col. 28 ll. 7 (emphasis added). The general method of
13
“authentication” is disclosed in the shared specification as follows:
14
15
16
17
18
19
20
21
22
23
24
25
26
27
A general object of the present invention is to provide a system and
method for reliably verifying via secure and tamper-proof documentation
the content and delivery of an electronic message such as an e-mail. . . .
. . . . To later verify and authenticate information contained in the
receipt, the originator or user sends a copy of the receipt to the system. The
system then verifies that the digital signature matches the original message
and the rest of the receipt. If the two match, then the system sends a letter
or provides other confirmation of authenticity verifying that the electronic
message has not been altered.
....
. . . . The encrypted message digest provides one type of message
authentication or validation code, or secure documentation. Other message
authentication and/or validation codes may also be generated and used.
‘389 Patent col. 3 ll. 6–61.
Having performed this calculation for each file attached to the
original message, the system prepares a report which reports on the
authenticity of the receipt and each of its attached files (710) or which
reports the failure of validation (712).
Id. col. 24 ll. 66–col. 25 ll. 3.
28
- 70 -
1
To begin, GoDaddy’s “comparing and matching” proposal is comparable to that of
2
the defendants before Judge Gilstrap who proposed “a comparison of two digital
3
fingerprints (hashes) to determine that they match.” RMail, 2013 WL 968246, at *59.
4
Judge Gilstrap analyzed that proposal as follows:
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
On balance, Defendants’ proposal of “a comparison of two digital
fingerprints (hashes) to determine that they match” is an aspect of a
preferred embodiment that should not be imported into the construction of
the comparatively generic term “authentication.” Electro Med. Sys., S.A. v.
Cooper Life Scis., Inc., 34 F.3d 1048, 1054 (Fed. Cir. 1994) (“[A]lthough
the specifications may well indicate that certain embodiments are preferred,
particular embodiments appearing in a specification will not be read into
the claims when the claim language is broader than such embodiments.”)
Id. The Court agrees with Judge Gilstrap. While the specification of the invention does
disclose that the server can compare and match certain information about the message to
authenticate the message, the claim itself uses broad language not limited to comparing
and matching. Thus, the Court refrains from reading limitations from the specification
into the claim and rejects this portion of GoDaddy’s proposal. See Teleflex, 299 F.3d at
1326 (“[L]imitations from the specification are not to be read into the claims[.]” (citing
Comark Commc’ns, 156 F.3d at 1186)).
As to GoDaddy’s proposed evidentiary limitation, the Court incorporates its
analysis as set forth in Term No. 7 and rejects the proposal. Specifically, even though
“authentication” is the second step of the “proof” process claimed by the Tomkow
Patents, the Court does not agree with GoDaddy that the status of the message—even
after authentication—must be tantamount to the evidentiary quality of registered United
States mail. The specification explicitly eschews the notion that any legal status be
afforded to a message, and the Court will not import any lingering evidentiary limitations
from the specification into the claim, particularly when the limitations relate to the “use”
of the invention.
Finally, RPost proposes that the jury be instructed that “the plain language of this
phrase does not require that any authentication of the message be performed by the
28
- 71 -
1
server.” (Doc. 191-1 at 6). The Court finds that including this sentence in the construction
2
is unnecessarily redundant as the phrase “before the message is authenticated” is readily-
3
understandable.
4
For these reasons, the Court construes “before the message is authenticated (any
5
authentication of the message) by the server” as “before the content and delivery of the
6
message is proved (proving the content and delivery of the message) by the server.”
7
8
R.
“Mail Transport Agent” (Term No. 18)
1.
The Parties’ Positions
9
RPost argues that MTA should be interpreted as “software that transfers electronic
10
messages from one computer to another.” (Doc. 191-1 at 7). RPost explains that this
11
construction is consistent with “dictionary” definitions of MTA. (Doc. 114 at 13 (citing
12
http://en.wikipedia.org/wiki/Message_transfer_agent)).
13
GoDaddy proposes that MTA should be construed as “software that resides on the
14
server and that is dedicated to transferring and receiving electronic messages from one
15
computer to or from another.” (Doc. 191-1 at 7). GoDaddy stresses that its definition
16
means that “the software, not the server” is “dedicated” to the transfer and receipt of
17
messages. (Doc. 117 at 15). GoDaddy also argues that the MTA must be installed on the
18
server “because the asserted claims are directed to servers that send and receive
19
messages.” (Id.)
20
RPost denounces GoDaddy’s proposal because “[a]lthough MTA software may be
21
installed on a server, the plain claim language and the intrinsic record do not require that
22
MTA software always be installed on a server or that the server be dedicated to
23
transferring electronic messages.” (Doc. 114 at 13). RPost underscores that the server can
24
also “record[] some portion of the selected one of the SMTP and ESMTP protocol dialog
25
between the server and the recipient.” (Id.) RPost further contends that construing MTA
26
as residing on “the server” is redundant and confusing because the jury will not know on
27
which server the MTA resides. (Doc. 119 at 8).
28
- 72 -
2.
1
Analysis
2
“Mail Transport Agent” is used in the ‘913 Patent as follows:
3
1. A method of transmitting a message from a sender to a recipient
through a server acting as a Mail Transport Agent, including the steps at the
server of:
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
transmitting the message to the recipient’s Mail Transport Agent in a
protocol dialog selected from a group consisting of the selected one of the
SMTP and ESMTP protocols; and
recording at the server some portion of the selected one of the SMTP
and ESMTP protocol dialog between the server and the recipient through
the server including those portions of the selected one of the SMTP and
ESMTP protocol dialog between the server and the recipient in which the
receiving Mail Transport Agent accepts or declines delivery of the
transmitted message.
‘913 Patent col. 27 ll. 41–54 (emphasis added). While the parties agree that MTA is
software that can transfer messages, their proposals diverge in three respects.
The first dispute concerns whether the construction should state where the MTA
software is located. In this regard, the Court agrees with GoDaddy that the construction
should include the MTA software’s location, but also finds merit in RPost’s concern that
if the construction reads “the server,” the jury could be confused as to which server
contains the MTA. Thus, the Court adopts a modified version of GoDaddy’s proposal:
“resides on a server.”
Second, because the MTA software is acting as an intermediary between the
sender and recipient, the Court agrees with GoDaddy that the MTA must be able to
“receive” electronic messages. See ‘913 Patent col. 27 ll. 48–54.
Finally, the Court rejects GoDaddy’s contention that the MTA software must be
“dedicated to” transferring and receiving electronic messages. “Dedicated to” imports
unnecessary ambiguity into the construction.
For these reasons, the Court construes MTA as “software that resides on a server
and that transfers and receives electronic messages from one computer to or from
another.”
- 73 -
1
S.
“sender” (Term No. 19) and “recipient” (Term No. 20)
1.
2
The Parties’ Positions
3
RPost argues that the terms “sender” and “recipient” have plain and ordinary
4
meanings that require no further construction from the Court. (Doc. 191-1 at 7). RPost
5
emphasizes that Judge Gilstrap gave these terms plain meaning constructions and urges
6
the Court to adopt a similar plain meaning construction. (Doc. 114 at 13).12 Alternatively,
7
RPost proposes that “sender” be construed as “originator of a message” and “recipient”
8
as “who the sender intends to receive the message.” (Id.)
9
GoDaddy responds that no plain meaning of the terms resolves the parties’ dispute
10
and criticizes RPost’s alternative constructions as “impermissibly vague.” (Doc. 117 at
11
15–16). Instead, GoDaddy proposes that “sender” be construed as “the computer that
12
originates the message” and “recipient” as “the computer that receives the message at its
13
intended destination.” (Doc. 191-1 at 7). According to GoDaddy, the Tomkow Patents
14
“provide” that the terms are “computers” because the shared specification recites that the
15
“sender” “create[s] the original messages” and “has both a name and Internet address,
16
and only computers have .com Internet addresses as recited in the patents.” (Doc. 117 at
17
15–16).
18
RPost replies that because the Tomkow Patents “repeatedly equate a user (i.e., a
19
person) with ‘sender,’” GoDaddy’s “computer” proposal violates the intrinsic record.
20
(Doc. 119 at 8–9). RPost also protests that GoDaddy’s construction violates the doctrine
21
of claim differentiation because it defines “sender” and “recipient” in the same way as
22
“originating processor” and “recipient processor.” (Doc. 114 at 13–14). RPost contends
23
that because the inventor used different words in the claims, there is a presumption that
24
he intended the terms to have different meanings. (Id. (citing Comark Commc’ns, 156
25
F.3d at 1187)). For its part, GoDaddy argues that the claim differentiation doctrine should
26
27
28
12
Judge Gilstrap analyzed these terms as used in the Feldbau Patent. See RMail,
2013 WL 968246, at *25–27.
- 74 -
1
not be applied here “in light of the patents’ disclosure of the meaning of these terms.”
2
(Doc. 117 at 16).
3
4
5
6
7
2.
Analysis
The claim terms “sender” and “recipient” are peppered throughout the Tomkow
Patents. A few examples include:
1. A method of transmitting a message from a sender to a recipient
through a server displaced from the recipient, the steps at the server
comprising:
8
receiving the message at the server from the sender
9
...
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
receiving at the server at least a portion of a mail transport protocol
dialog generated during transmission of the message from the server to the
recipient; and
receiving at the server from the recipient an indication of the receipt
of the message by the recipient;
forming at the server a first information from the at least a portion of
the mail transport protocol dialog and the indication of the receipt of the
message by the recipient; and
transmitting, before any authentication of the message, a copy of the
message and the first information to the sender from the server.
‘389 Patent col. 27 ll. 58–col 28 ll. 7 (emphasis added).
1. A method of transmitting a message from a sender to a recipient
and providing an indication that the message was opened by the recipient,
comprising:
...
adding a link to the message by the server, the link configured to
execute when the message is opened at the recipient to provide an
indication that the message has been opened by the recipient,
executing the link when the message is opened at the recipient to
control the server to provide an indication that the message has been
opened at the recipient,
providing an authenticatible information related to the message,
including the indication of the opening of the message at the recipient, at
the server,
28
- 75 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
transmitting the indication of the opening of the message at the
recipient, and the authenticatible information from the server to the sender,
‘104 Patent col. 27 ll. 63–col. 28 ll. 16 (emphasis added).
To support its position that “sender” and “recipient” should be defined as
“computers,” GoDaddy cites to the following sentence of the shared specification: “[f]or
example, where the original sender of the message is user John Smith with Internet
address jsmith@adomain.com . . . .” ‘199 Patent col. 9 ll. 53–54. GoDaddy explains that
“sender” and “recipient” must be construed to mean “computers” because only computers
have Internet addresses. (Doc. 117 at 15–16).
In this regard, the Court finds that the presence of the phrase “user John Smith”
forecloses construing “sender” strictly as “computer.” While it may technically be true
that only computers have Internet addresses, a “user”—disclosed here as the “original
sender”—is not necessarily a computer. Auxiliary disclosures in the specification equate
“sender” with “user” and “originator.” See ‘199 Patent col. 18 ll. 37–39 (“To register an
e-mail message, in step 201 an originator/sender/user creates an email message using
any Internet Mail User Agent (MUA).”). While it is undisputed that the asserted claims
involve electronic methods of transmitting information, “sender” is best understood as a
combination of both the user causing the computerized device to originate the message
and the computerized device itself. In fact, GoDaddy’s own argument supports this
conclusion. See (Doc. 117 at 15 (“The specification also provides that the ‘sender’ has
both a name and Internet address . . . .” (emphasis added))).
Correspondingly, the specification also forecloses construing “recipient” as
“computer.” For example, the specification discloses that “[n]otifications will not be
generated, if ever, until the recipient opens his MUA e-mail client and takes some action
with respect to the received mail.” Id. col. 15 ll. 46–49 (emphasis added). The
specification further explains that “MUA notices may report, among other things, that a
message has been read by a recipient . . . .” Id. col. 15 ll. 63–64 (emphasis added). Thus,
28
- 76 -
1
the intrinsic record compels defining “recipient” in a manner that includes both the user
2
and the device.
3
Finally, GoDaddy proposes that “recipient” should be defined with the limitation
4
“at its intended destination” but did not explain this modification in its briefing or during
5
the Markman Hearing. See (Doc. 117 at 15–16). The Court finds this phrase to be
6
ambiguous and therefore does not incorporate it in the construction.
7
For these reasons, the Court construes “sender” as “a combination of (1) the user
8
that caused the computerized device to originate the message and (2) the computerized
9
device itself” and “recipient” as “a combination of (1) the user that the sender intends to
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
receive the message and (2) the computerized device that receives the message.”
T.
“originating processor” (Term No. 21) and “recipient processor”
(Term No. 22)
1.
The Parties’ Positions
RPost argues that “originating processor” and “recipient processor” need not be
construed because the terms are used according to their plain and ordinary meanings.
(Doc. 191-1 at 7). Alternatively, RPost proffers that “originating processor” be construed
as “a computing device where the message originates” and “recipient processor” as “a
computing device where the recipient receives the message.” (Id.) RPost explains that a
skilled artisan would understand that electronic messages can be “sent and received using
computing devices other than computers.” (Doc. 119 at 9).
GoDaddy proposes the same respective constructions as it did for “sender” (Term
No. 19) and “recipient” (Term No. 20). See (Doc. 191-1 at 7). Thus, GoDaddy defines
“processor” as “computer.” (Id.)
RPost attacks GoDaddy’s proposal for “originating processor” as being “too
narrow because it requires that the computer itself originate the message and excludes the
[far] more . . . likely case of a user originating a message at a computer.” (Docs. 114 at
14; 119 at 9). RPost also claims that GoDaddy’s proposed language “at its intended
28
- 77 -
1
destination” is flawed because it is unclear what such a limitation actually connotes in the
2
electronic message context. (Docs. 114 at 14; 119 at 9).
3
2.
Analysis
4
These two terms are used in the ‘104 and ‘389 Patents as follows:
5
27. A system for transmitting a message from an originating
processor to a recipient processor in an electronic mail system and
providing an indication that the message was opened by the recipient
processor, comprising:
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
a server in electronic communication in the electronic mail system,
the server receiving the message from the originating processor and adding
a link to the message before transmitting the message and link to the
recipient processor, the link being configured to execute automatically
when the message is opened at the recipient processor to control the server
to provide an indication at the server that the message has been opened at
the recipient processor . . . .
‘104 Patent col. 31 ll. 20–32 (emphasis added).
7. A system for transmitting a message through an electronic mail
system from an originating processor to a recipient processor and providing
proof of receipt of the message by the recipient process[or], comprising:
a server displaced from the originating processor, the server capable
of being configured by software commands to:
receive a message from the originating processor and to transmit the
message to the recipient processor,
receive an indication of receipt of the message from the recipient
processor and a mail transport protocol dialog generated by the electronic
mail system during transmission of the message from the server to the
recipient processor;
generate a first information including the indication of receipt of the
message from the recipient processor and at least a portion of the mail
transport protocol dialog generated by the electronic mail system during
transmission of the message from the server to the recipient processor.
‘389 Patent col. 28 ll. 33–52 (emphasis added).
To begin, the Court finds that the jury would be aided by defining these terms.
RPost’s own argument proves construction is necessary. Namely, there is a semantical
dispute as to whether the “originating processor” is a device “that” originates the message
- 78 -
1
or if it is “where” the message originates. Likewise, there is a dispute whether the
2
“recipient processor” is “where” the message is received by the recipient or if it is a
3
device “that” receives the message. Absent construction, the jury could be confused on
4
these issues.
5
In light of the Court’s construction of “sender,” the Court concludes that
6
“originating processor” is “where” the message originates. A combination of the user
7
interfacing with the originating processor originates the message, and this occurs at the
8
originating processor. Thus, the Court adopts this portion of RPost’s alternative proposal.
9
Conversely, the Court finds that “recipient processor” is best understood as the
10
device “that” receives the message for the recipient. Unlike when a message originates
11
through an interaction between the user and originating processor, when a message is
12
received, it is the processor—not the user—“that” receives the message. The user may
13
open the electronic message at the processor, but it is the processor that receives the
14
message.
15
Finally, the Court must resolve whether “processor” should be construed as
16
“computing device” or “computer.” RPost complains that “computer” is too narrow,
17
while GoDaddy laments that “computing device” is too vague. To resolve this dispute,
18
the Court looks to how a skilled artisan would view the term “processor.” On one hand, a
19
skilled artisan would recognize that “processor” means a “computer,” a “central
20
processing unit” (“CPU”), or a “program that translates another program into a form
21
acceptable by the computer being used.” See Am. Heritage Dictionary of the English
22
Language 1398 (4th ed. 2006). On the other hand, a skilled artisan would also appreciate
23
“CPU” to mean “the device that interprets and executes instructions.” Microsoft
24
Computer Dictionary 92 (5th ed. 2002) (emphasis added).
25
On balance, the Court finds that because the plain meaning of “processor”
26
includes “computer,” the word “computer” should be assimilated in the construction.
27
However, it appears that a skilled artisan would understand that other types of devices
28
with processors could send and receive messages. The Court, therefore, construes
- 79 -
1
“originating processor” as “the computerized device where the message originates” and
2
“recipient processor” as “the computerized device that receives the message.”
3
U.
4
1.
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
23
24
25
26
27
28
The Parties’ Positions
The crux of the parties’ disagreement over Term No. 23 is whether the phrase is
limiting upon the claim. Because the phrase is found only in the preamble of Claim 7 of
the ‘389 Patent, RPost contends that it is not limiting because it does not give life,
meaning, and vitality to the claim. (Doc. 114 at 14). RPost argues that the inventor
simply used the phrase to “state the purpose or intended use of the claimed system” and
that the body of the claim is “structurally complete.” (Id.)
In contrast, GoDaddy proffers a construction of “providing evidence that confirms
receipt of the message by the recipient, the evidence providing a legal or other
evidentiary status on par with, if not superior to, that of registered United States mail.”
(Doc. 117 at 10).13 Because Claim 7 does not include any “authentication” terms,
GoDaddy insists that construction is necessary to provide an “essential limitation” to the
claim. (Id. at 11). GoDaddy further defends its construction by remarking that the
preamble must be construed in order to “capture the purported invention’s core concept
of providing proof regarding the delivery and content of an e-mail message and to
differentiate claim 7 from prior art.” (Id. (citation omitted)).
2.
21
22
“providing proof of receipt of the message by the recipient processor”
(Term No. 23)
Legal Standard
Whether a preamble limits a claimed invention is a question of law and is
“resolved only on review of the entire patent to gain an understanding of what the
inventors actually invented and intended to encompass by the claim.” Catalina Mktg.,
13
GoDaddy’s proposed construction as recorded in its briefing does not correlate
with the parties’ Amended Joint Claim Construction Statement. See (Docs. 117 at 10;
191-1 at 8). In the Amended Joint Claim Construction Statement, GoDaddy’s proposal is
listed as “providing proof of receipt of the message by the recipient processor.”
(Doc. 191-1 at 8). The Court will analyze GoDaddy’s proposal as outlined in its briefing.
- 80 -
1
Int’l v. Coolsavings.com, Inc., 289 F.3d 801, 807–08 (Fed. Cir. 2002) (quotation
2
omitted). A preamble may limit the invention if it “recites essential structure or steps, or
3
if it is ‘necessary to give life, meaning and vitality’ to the claim.” Id. (quoting Pitney
4
Bowes, Inc. v. Hewlett–Packard Co., 182 F.3d 1298, 1305 (Fed. Cir. 1999)). “When the
5
preamble is essential to understand limitations or terms in the claim body, the preamble
6
limits claim scope.” Id. (citing Pitney Bowes, 182 F.3d at 1306).
7
Conversely, a preamble is not limiting “where a patentee defines a structurally
8
complete invention in the claim body and uses the preamble only to state a purpose or
9
intended use for the invention.” Id. (citing Rowe v. Dror, 112 F.3d 473, 478 (Fed. Cir.
10
1997)). Furthermore, “preamble language merely extolling benefits or features of the
11
claimed invention does not limit the claim scope without clear reliance on those benefits
12
or features as patentably significant.” Id. at 809 (citations omitted).
13
Finally, “preambles describing the use of an invention generally do not limit the
14
claims because the patentability of apparatus or composition claims depends on the
15
claimed structure, not on the use or purpose of that structure.” Id. (citation omitted).
16
Indeed, “[t]he inventor of a machine is entitled to the benefit of all the uses to which it
17
can be put, no matter whether he had conceived the idea of the use or not.” Id. (quotation
18
omitted). “Again, statements of intended use or asserted benefits in the preamble may, in
19
rare instances, limit apparatus claims, but only if the applicant clearly and unmistakably
20
relied on those uses or benefits to distinguish prior art.” Id.
21
22
23
24
25
26
27
3.
Analysis
Term No. 23 appears only in the preamble of Claim 7 of the ‘389 Patent. Claim 7,
in its entirety, reads:
7. A system for transmitting a message through an electronic mail
system from an originating processor to a recipient processor and providing
proof of receipt of the message by the recipient process, comprising:
a server displaced from the originating processor, the server capable
of being configured by software commands to:
28
- 81 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
receive a message from the originating processor and to transmit the
message to the recipient processor,
receive an indication of receipt of the message from the recipient
processor and a mail transport protocol dialog generated by the electronic
mail system during transmission of the message from the server to the
recipient processor;
generate a first information including the indication of receipt of the
message from the recipient processor and at least a portion of the mail
transport protocol dialog generated by the electronic mail system during
transmission of the message from the server to the recipient processor.
‘389 Patent col. 28 ll. 33–52 (emphasis added). The question before the Court is whether
“providing proof of receipt of the message by the recipient processor” is necessary to
give life, meaning and vitality to Claim 7 or else recites essential steps or structure.
As GoDaddy observes, unlike the rest of the asserted claims in the Tomkow
Patents, Claim 7 does not include any “authentication” terminology. The invention’s
ability to authenticate, i.e., verify or prove, a certain aspect of a message—such as
delivery or non-delivery—is necessary to differentiate the invention from prior art. In this
regard, RPost argues that Claim 7 expresses “several proofs of receipt of the message,
including ‘an indication of receipt of the message’ and ‘a mail transport protocol dialog
generated during transmission of the message.’” (Doc. 114 at 14–15).14 As discussed for
Term No. 4, however, providing an “indication” is merely the first step in the two-step
“proof” process. The “proof of receipt” emerges not from the “indication” or “dialog” but
from “authentication”—the second step which is absent from the body of Claim 7.
21
22
23
24
25
26
27
28
14
GoDaddy contends that this argument is internally inconsistent. (Doc. 117 at
10–11). The Court agrees. RPost argues that there are several “proofs of receipt” recited
in the body of Claim 7 but only points to the “indication” and “dialog” language. See
(Doc. 114 at 14–15). RPost concedes, however, that the “proof” of receipt occurs when
the message is “authenticated”—not when an “indication” or “dialog” is generated. See
(Doc. 191-1 at 6 (construing “before the message is authenticated” as “before the content
and delivery of the message is proved”)). As explained in Term No. 4, the Tomkow
Patents integrate a two-step process to prove the delivery and content of a particular
message. It is inconsistent for RPost to construe “indication” merely as “information that
indicates” but then turn around and argue that an “indication” is also “proof of receipt.”
- 82 -
1
Accordingly, the Court finds that “providing proof of receipt of the message” is a
2
necessary limitation upon Claim 7 and must be construed.15
3
As to the construction of Term No. 23, GoDaddy’s proposal again requires the
4
invention to provide proof with a “legal or other evidentiary status on par with, if not
5
superior to, that of registered United States mail.” (Doc. 191-1 at 8). As explained for
6
Term Nos. 7 and 17, however, the Tomkow Patents do not impose that evidentiary
7
limitation on its messages.16 Instead, because the term “authenticated” from Term No. 17
8
is analogous to the disputed claim term here, the Court finds that a similar construction is
9
appropriate.
10
For these reasons, the Court concludes that Term No. 23 limits Claim 7 of the ‘389
11
Patent and adopts a construction of: “proving that the message was received by the
12
recipient processor.”
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
15
The Court notes that the specification is riddled with references to “proving,”
“authenticating,” or “verifying” some aspect of the message, underscoring the importance
of the feature to the claimed invention. See Rotatable Techs. LLC v. Motorola Mobility
LLC, 567 F. App’x 941, 943 (Fed. Cir. 2014). For example, the ‘389 Patent’s Title,
Abstract, Background of Invention, Summary of the Invention, Brief Description of the
Drawings, and Detailed Description of the Preferred Embodiments all recite either
“authentication, “verification,” or “proving.” See ‘389 Patent (54), (57), col. 1 ll. 21, col.
3 ll. 7, col. 5 ll. 60, col. 17 ll. 1–65.
16
Notably, “proving” an aspect of the message is not, as RPost contends, merely a
“use” of the invention. Instead, it is a distinguishing function of the invention requiring
adequate structure. On the other hand, the “evidentiary” limitation GoDaddy repeatedly
proposes is a “use” of the invention. Namely, whether the “proof” that the invention
provides equates to “a legal or other evidentiary status on par with, or superior to
registered United States mail” speaks to the ability to “use” the invention for a specific
purpose. The function of “proving” is not so narrow and “[t]he inventor of a machine is
entitled to the benefit of all the uses to which it can be put, no matter whether he had
conceived the idea of the use or not.” Catalina Mktg., 289 F.3d at 809 (quotation
omitted).
- 83 -
1
V.
2
1.
3
4
5
6
7
8
9
10
11
12
15
16
17
18
19
The Parties’ Positions
RPost argues that “the link configured to execute when the message is opened at
the recipient” should be construed as “the link programmed to execute when the message
is opened at the recipient.” (Doc. 191-1 at 8). RPost insists this slight modification is
necessary to clarify for the jury that the term is “used in a computer programming sense.”
(Doc. 119 at 10).
GoDaddy responds that RPost has not shown that “configured” is synonymous
with “programmed” and complains that RPost’s proposal changes the scope of the claim
term. (Doc. 117 at 16). Instead, GoDaddy contends that the phrase is “plain on its face”
and needs no construction. (Id.)
2.
13
14
“the link configured to execute when the message is opened at the
recipient” (Term No. 24)
Analysis
As explained for Term Nos. 8 and 9, “configured” is a term that has a plain
meaning that the jury will be able to understand. RPost has not shown that the term is
used in a manner that is contrary to that plain meaning. Consequently, the Court does not
construe Term No. 24.
W.
“the server (being) displaced from the recipient (recipient processor)”
(Term No. 25)
1.
The Parties’ Positions
20
For the twenty-fifth disputed term of the Tomkow Patents, RPost recommends a
21
construction of “the server (being) logically displaced from the recipient (recipient
22
processor).” (Doc. 191-1 at 8). RPost contends this construction will “clarify the meaning
23
of the plain language of the claim[] for the benefit of the jury [and does] not otherwise
24
change the meaning of the claim[].” (Doc. 114 at 15).
25
GoDaddy responds that RPost’s proposed construction is not synonymous with the
26
claim language and “changes the meaning and scope of the term.” (Doc. 117 at 16).
27
28
- 84 -
1
Instead, GoDaddy argues that no construction is needed because the term is used
2
according to its plain and ordinary meaning. (Id.)
3
RPost replies that construing the term “displaced” as “logically displaced” would
4
simplify for the jury that the server and recipient are separated “in a computer
5
architecture sense but not necessarily physically separate.” (Doc. 119 at 10).
2.
6
Analysis
7
This phrase is used in Claims 1 and 23 of the ‘104 Patent; Claims 1, 7, 14, and 15
8
of the ‘389 Patent; all asserted claims for the ‘199 Patent; and Claim 1 of the ‘198 Patent.
9
For example, the ‘104 and ‘198 Patents claim:
10
11
12
1. A method of transmitting a message from a sender to a recipient
and providing an indication that the message was opened by the recipient,
comprising:
13
receiving the message at a server from the sender, the server being
displaced from the recipient . . . .
14
‘104 Patent col. 27 ll. 63–67 (emphasis added); see ‘198 Patent col. 28 ll. 6–10 (same).17
15
RPost’s proposal injects “logically” before the claim term “displaced.” Contrary to
16
RPost’s argument, such a construction adds ambiguity to a readily understandable term.
17
RPost has not shown that the jury would be confused as to the meaning of the generic
18
term “displaced.” Accordingly, the Court will not construe Term No. 25 and adopts
19
GoDaddy’s proposal of ordinary meaning.
20
X.
21
22
23
24
“the server constructs authenticatible information related to the
message” (Term No. 26)
1.
The Parties’ Positions
RPost argues that the claim term “constructs” should be construed as “assembles”
because such a construction would “clarify the meaning of the plain language of the
claim[] for the benefit of the jury [and does] not otherwise change the meaning of the
25
26
27
17
No asserted claim uses the term “recipient processor.” Thus, the Court rejects
this portion of RPost’s proposed construction.
28
- 85 -
1
claim[].” (Doc. 114 at 15). Thus, RPost proffers a construction of: “the server assembles
2
authenticatible information related to the message.” (Doc. 191-1 at 8).
3
GoDaddy responds that RPost has not shown that “assembles” is synonymous
4
with “constructs” and asks the Court to reject RPost’s proposal. (Doc. 117 at 16).
5
According to GoDaddy, “constructs” is a “readily-understood” term that the jury will be
6
able to apply without further construction. (Id.)
7
RPost replies that its construction is necessary because it clarifies for the jury that
8
“constructs” means the “assembling of information, such as described in the creation of a
9
delivery receipt.” (Doc. 119 at 10). At the Markman Hearing, RPost further explained its
10
position by noting that the jury could misinterpret “constructs” as creating from new or
11
from scratch, versus taking and assembling information that already exists. According to
12
RPost, “constructs” as used in the ‘104 Patent does not require the server to create new
13
information.
14
2.
Analysis
15
This disputed phrase is used in Claim 27 of the ‘104 Patent as follows:
16
27. A system for transmitting a message from an originating
processor to a recipient processor in an electronic mail system and
providing an indication that the message was opened by the recipient
processor, comprising:
17
18
19
20
21
22
23
a server in electronic communication in the electronic mail system,
the server receiving the message from the originating processor and adding a
link to the message before transmitting the message and link to the recipient
processor . . .
wherein the server constructs authentication information related to
the message . . . .
‘104 Patent col. 31 ll. 20–34 (emphasis added).
24
The Court agrees with GoDaddy that RPost failed to show that “constructs” should
25
be construed as “assembles.” The Meriam-Webster Dictionary defines “construct” as “to
26
make or form by combining or arranging parts or elements.” The Merriam-Webster
27
Dictionary, http://www.merriam-webster.com/dictionary/construct (last visited January
28
- 86 -
1
19, 2016). On the other hand, “assemble” is defined as “to bring together” or “to fit
2
together the parts of.” Id., http://www.merriam-webster.com/dictionary/assemble (last
3
visited January 19, 2016). As readily seen, these two words have different meanings.
4
As used in Claim 27, “constructs” requires that the server take certain information
5
and “construct” something else, namely, “authenticatible information.” The server does
6
not merely “assemble” the pre-existing information to form the authenticatible
7
information. A simple example makes this distinction clear. When a builder “constructs”
8
a backyard patio, he combines various pre-existing items—such as wood, paint, and
9
nails—in a way that creates a new item comprised of the pre-existing items: the patio. If
10
the builder simply were to “assemble” the wood, paint, and nails by gathering them into
11
one place, without more, he would have “constructed” nothing.
12
Here, Claim 27 does not merely state that the server “assembles” together various
13
forms of pre-existing information, but claims that the server “constructs authenticatible
14
information.” Because RPost has not shown that the inventor unequivocally chose to
15
define “constructs” in a manner different from the term’s plain meaning, the Court rejects
16
RPost’s proposed construction and does not construe the term. See Omega Eng’g, 334
17
F.3d at 1324.
18
VII.
19
20
Claim Construction of Disputed Claim Terms in the Feldbau Patent
A.
“authenticating a dispatch and contents of the dispatch” (Term No. 1)
1.
The Parties’ Positions
21
RPost urges the Court to adopt the construction of this phrase as crafted by Judge
22
Gilstrap. (Doc. 114 at 13). Judge Gilstrap reasoned that the claim and specification
23
language make clear that the patent’s objective is to provide “evidence” that “can” be
24
used by the sender to later prove aspects related to the dispatch. See RMail, 2013 WL
25
968246, at *7–8. Espousing this reasoning, RPost contends that “authenticating a
26
dispatch and contents of the dispatch” should be construed as “provide evidence capable
27
of being used to prove the contents of the dispatch.” (Doc. 114 at 13).
28
- 87 -
1
GoDaddy responds that RPost’s proposed construction is flawed in multiple
2
respects. (Doc. 117 at 17). First, GoDaddy explains that RPost’s construction forsakes the
3
“conjunctive structure” of the phrase. (Id.) Namely, by providing evidence concerning
4
only the contents of the dispatch, GoDaddy argues that RPost’s construction reads out
5
claim language requiring proof that the message was dispatched. (Id.) Second, GoDaddy
6
contends that RPost’s construction is “too loose” a standard for the higher level of
7
“proof” purportedly embodied in the Feldbau Patent. (Id.) GoDaddy therefore proposes a
8
construction of “proving the contents and the receipt of a dispatch by using reliable
9
evidence on par with that used to notarize documents or to admit as evidence in a court of
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
law.” (Id.)
RPost replies that GoDaddy’s proposed construction improperly incorporates
limitations from the specification into the claim. (Doc. 119 at 10).
2.
Analysis
The phrase “authenticating a dispatch and contents of the dispatch” is disclosed in
Claims 60 and 82 of the Feldbau Patent. Claim 60 discloses:
60. A method of authenticating a dispatch and contents of the
dispatch successfully transmitted from a sender to a recipient . . .
...
Associating, by [an] the authenticator functioning as a noninterested third party with respect to the sender and the recipient, the
content data with dispatch record data which includes at least said time
related indicia and an indicia related to the destination of the dispatch, to
generate authentication data which authenticate the dispatch and the
contents of the dispatch . . . .
‘219 Patent col. 2 ll. 56–col. 3 ll. 7 (amended version) (amendments by Ex Parte
Reexamination Certificate are shown with additions underlined; deletions in bolded
square brackets; italics added for emphasis). Similarly, Claim 82 discloses:
82. An information dispatch system in an electronic communication
network comprising:
...
28
- 88 -
1
2
3
4
an authenticator functioning as a non-interested third party with
respect to the sender and the recipient for authenticating the dispatch and
contents of the dispatch transmitted from the source transmitting system to
the destination receiving system . . . .
Id. col. 4 ll. 4–18 (emphasis added).
5
Initially, the Court agrees with Judge Gilstrap that the specification makes clear
6
that “authenticating”—as the term is used by the Feldbau Patent—merely means storing
7
evidence of the dispatch and its content without simultaneous verification or validation of
8
the dispatch and its content. For example, the specification describes the Feldbau Patent’s
9
objective as providing “evidence” that “can” be used by the sender:
10
11
12
13
It is therefore the object of the present invention to improve the
capacity of conventional systems and methods for dispatching documents
and transmitting information to provide the sender with evidence he can use
to prove both the dispatch and its contents.
‘219 Patent col. 2 ll. 57–61 (emphasis added). The specification also discloses:
19
When it is desired to authenticate the dispatch of the original
documents (and possibly also their receipt at the destination 30), either the
sender or the document dispatching service provides the associated
authentication-information, for example the envelope 32, unopened, to the
party which required the authentication. When the envelope 32 is opened, it
has associated therewith copies of both the dispatched documents and the
dispatch information. The envelope 32 therefore, provides reliable proof
that the original documents 12 were dispatched on the date and to the
destination listed on or in envelope 32.
20
Id. col. 5 ll. 63–col. 6 ll. 6 (emphasis added). The Court therefore rejects GoDaddy’s
21
argument that “authenticating” should be construed as “proving.”
14
15
16
17
18
22
Moreover, as Judge Gilstrap explained, to “authenticate” a message, the invention
23
does not speak in terms of the recipient’s “receipt” of the message. See RMail, 2013 WL
24
968246, at *7–9. Rather, the claim relates only to the “dispatch” of the information while
25
“receipt” is part of the later optional aspect of “verification.” Id. Thus, the Court rejects
26
GoDaddy’s proposal of “proving the . . . receipt of a dispatch.”
27
On the other hand, the Court gives credence to GoDaddy’s argument that the
28
phrase “authenticating the dispatch and contents of the dispatch” is facially conjunctive.
- 89 -
1
The specification emphasizes the conjunctive nature of the claim by disclosing that the
2
invention will “provide the sender with evidence he can use to prove both the dispatch
3
and its contents.” ‘219 Patent col. 2 ll. 60–61 (emphasis added); see id. col. 3 ll. 22–24
4
(“Thus, the present invention provides a sender with the capability to prove both the
5
dispatch and the contents of the dispatched materials.” (emphasis added)). Providing
6
evidence capable of proving both the dispatch and its contents is plainly the objective of
7
the Feldbau Patent and distinguishes the invention from prior art. See id. col. 2 ll. 30–42;
8
id. col. 2 ll. 50–53. Accordingly, the Court’s construction requires that the invention
9
provide evidence that “can” be used to prove both (1) the dispatch itself and (2) the
10
contents of the dispatch.
11
GoDaddy also contends that, as embodied by the Feldbau Patent, the quality of
12
evidence provided by the invention must rise to a higher level of “proof” than mere
13
“evidence.” (Doc. 117 at 17). To supports its argument, GoDaddy references the entirety
14
of the specification’s Background of the Invention and Summary of the Present
15
Invention. (Id. (citing ‘219 Patent col. 1 ll. 30–col. 2 ll. 17; id. col. 2 ll. 50–col. 4 ll. 39)).
16
RPost responds that such a construction would improperly read limitations from the
17
specification into the claim, and, in any event, rejects the contention that GoDaddy’s
18
proposed limitation language is even disclosed in the specification. (Doc. 119 at 10).
19
The Court agrees with RPost that GoDaddy’s proposal requiring the claimed
20
“evidence” to be “reliable evidence on par with that used to notarize documents or to
21
admit as evidence in the court of law” would improperly import limitations from the
22
specification into the claim. Throughout the claims, the inventor chose merely to claim
23
“evidence” or “proof,” not the higher level of proof that GoDaddy contends is embodied
24
in the specification. For example, the specification discloses:
25
26
27
It is therefore an object of the present invention to improve the capacity of
conventional systems and methods for dispatching documents and
transmitting information to provide the sender with evidence he can use to
prove both the dispatch and its contents.
28
- 90 -
1
‘219 Patent col. 2 ll. 57–61 (emphasis added). The section of the specification upon
2
which GoDaddy so heavily relies does not convince the Court that the inventor chose to
3
forego the broader meaning of the term “evidence” by limiting the term to “reliable
4
evidence on par with that used to notarize documents or to admit as evidence in the court
5
of law.” Specifically, the Background of the Invention merely provides the reader with
6
context as to the state of the present art, see id. col. 1 ll. 30–col. 2 ll. 17, while the
7
Summary of the Present Invention is best understood as offering an example of how the
8
evidence might be used, see id. col. 2 ll. 50–col. 4 ll. 39. See Phillips, 415 F.3d at 1323
9
(“To avoid importing limitations from the specification into the claims, it is important to
10
keep in mind that the purposes of the specification are to teach and enable those of skill
11
in the art to make and use the invention and to provide a best mode for doing so.”). These
12
disclosures do not evidence the inventor’s “clear disavowal” of claim scope. See Thorner,
13
669 F.3d at 1365 (quoting Teleflex, 299 F.3d at 1325).
14
In fact, these portions of the specification provide additional support that the
15
inventor intended only to claim the term “evidence.” See id. col. 2 ll. 50–56 (“The
16
literature does not provide a comprehensive solution that directly addresses the problem
17
in question: what information has been sent to whom and when. Accordingly, there is a
18
need for a method and system to provide the sender with a convenient means for
19
authenticating both the dispatch and the contents of the documents, electronic
20
information and other information during the normal flow of daily activities.”); id. col. 3
21
ll. 22–24 (“Thus, the present invention provides a sender with the capability to prove both
22
the dispatch and the contents of the dispatched materials.”). The distinguishing feature of
23
the invention concerns not—as GoDaddy asserts—the quality of the evidence, but the
24
combination of providing evidence capable of being used to prove both the dispatch and
25
its contents.
26
For these reasons, the Court construes “authenticating a dispatch and contents of
27
the dispatch” as “providing evidence that is capable of being used to prove both the
28
dispatch and the contents of the dispatch.”
- 91 -
1
2
B.
“authentication data” (Term No. 2)
1.
The Parties’ Positions
3
The parties agree that the majority of Judge Gilstrap’s construction of
4
“authentication data” should be adopted, but RPost proposes a modified construction due
5
to a difference in the asserted claims. RPost argues that the term should be construed as
6
“information that is associated with the contents of the dispatch by generating a
7
representation of at least content data, an indicia of a time of successful transmission of
8
the dispatch to the recipient, and an indicia relating to the destination of the dispatch, the
9
representation comprising one or more elements.” (Doc. 114 at 16). In contrast, GoDaddy
10
parrots Judge Gilstrap’s construction of “information that is associated with the contents
11
of the dispatch by generating a representation of at least a1, a2, and a3, the representation
12
comprising one or more elements.” (Doc. 117 at 17).
13
RPost replies that GoDaddy’s construction is flawed because Claim 30—where
14
a1, a2, and a3 are defined—was being asserted in the dispute before Judge Gilstrap but
15
has not been asserted against GoDaddy here. (Doc. 119 at 11). Because a1, a2, and a3
16
have not been defined by an asserted claim, RPost argues that construing this term with
17
“a1, a2, and a3” would only confuse the jury. (Id.) RPost therefore proposes a
18
construction that replaces the a1, a2, and a3 language with the elements as listed in the
19
asserted claims. (Id.)
20
21
22
23
24
25
26
27
28
2.
Analysis
The term “authentication data” is used in Claims 60 and 82 of the Feldbau Patent.
Claim 60 states as follows:
60. A method of authenticating a dispatch and contents of the
dispatch successfully transmitted from a sender to a recipient, comprising
the steps of:
receiving content data representative of the contents of the dispatch
originated from the sender and being electrically transmitted to said
recipient, and a destination of the dispatch;
providing an indicia [relating to] of a time of successful
transmission of the dispatch to the recipient, said time related indicia being
- 92 -
1
2
3
4
5
6
recorded by an authenticator and provided in a manner resistant to or
indicative of tampering by either of the sender and the recipient;
associating by [an] the authenticator functioning as a non-interested
third party with respect to the sender and the recipient, the content data with
dispatch record data which includes at least said time related indicia and an
indicia relating to the destination of the dispatch, to generate authentication
data which authenticate the dispatch and the contents of the dispatch; and
7
securing by said authenticator, at least part of the authentication data
against tampering of the sender and the recipient . . . .
8
‘219 Patent col. 2 ll. 56–col. 3 ll. 13 (amended version) (amendments by Ex Parte
9
Reexamination Certificate are shown with additions underlined and deletions in bolded
10
square brackets; italics added for emphasis). The term is also used in Claim 82 as
11
follows:
12
13
14
15
16
17
18
19
82. An information dispatch system in an electronic communication
network comprising:
...
(3) a processor for associating the content data with dispatch record
data which includes at least said time related indicia and an indicia relating
to the destination of the dispatch, to generate authentication data which
authenticate the dispatch and the contents of the dispatch; and
(4) means for securing at least part of the authentication data against
tampering of the sender and the recipient . . . .
Id. col. 4 ll. 4–39 (emphasis added).
20
While GoDaddy proposes Judge Gilstrap’s exact construction, it goes without
21
saying that “a1, a2, and a3” do not appear in either Claim 60 or 82. GoDaddy insists,
22
nonetheless, that because the specification discloses a1, a2, and a3, the jury will
23
understand that together these three elements compose “authentication data.” (Doc. 117
24
at 18). The only portion of the specification that GoDaddy cites for its argument is the
25
Abstract, which states:
26
27
28
Apparatus and method for authenticating that a sender has sent
certain information via a dispatcher to a recipient is disclosed. The method
includes the steps of: (a) providing a set A comprising a plurality of
information elements a1, . . . an, said information element a1 comprising
- 93 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
the contents of said dispatched information, and said one or more
information elements, a2, . . . an comprising dispatch-related information
and comprise at least the following elements: a2—a time indication
associated with said dispatch; and a3—information describing the
destination of the dispatch, and wherein at least one of said information
elements is provided in a manner that is resistant or indicative of tamper
attempts by said sender, (b) associating said dispatch-related information
with said element at by generating authentication-information, in particular
comprising a representation of at least said elements a1, a2 and a3, said
representation comprising a set of one or more elements, each comprising a
representation of one or more elements of said set A . . . .
‘219 Patent (57). Two other portions of the specification disclose elements a1, a2, and a3,
but both expressly relate to other claims. See id. col. 2 ll. 62–col. 3 ll. 20 (relating to
Claim 1); id. col. 3 ll. 37–49 (relating to Claim 27). Two other claims—Claim 1 and
Claim 30—include elements a1, a2, and a3 with accompanying definitions, but RPost
does not assert either claim here. See ‘219 Patent col. 1 ll. 26–45, col. 2 ll. 11–27
(amended version).
When interpreting a term, the Court begins with the particular claim language used
in the patent. See Interactive Gift Express, Inc. v. Compuserve, Inc., 256 F.3d 1323, 1331
(Fed. Cir. 2001). Here, Claims 60 and 82 expressly disclose the types of information that
are “associated” together to “generate authentication data.” Id. col. 3 ll. 1–7, col. 4 ll. 31–
36. In generalized terms, this information includes content data and certain indicia related
to transmission of the dispatch. Id. Claims 60 and 82 do not, however, mention or refer to
elements a1, a2, and a3.18 Clearly, had the inventor wanted to include the a1, a2, and a3
language in either Claim 60 or 82 he could have done so.
The Court’s next step is to review the specification. See Compuserve, 256 F.3d at
1331. The only reference in the specification to the a1, a2, and a3 terms is found in the
Abstract. Beyond remaining faithful to Judge Gilstrap’s construction, GoDaddy provides
26
27
28
18
RPost is not asserting Claim 30 as it did before Judge Gilstrap, nor is RPost
asserting Claim 1. Thus, the jury’s only plausible reference point to the a1, a2, and a3
terminology is the Abstract.
- 94 -
1
no other reason for the Court to stray from the express limitation language used in Claims
2
60 and 82 in order to introduce “a1, a2, and a3”—terminology that is not incorporated in
3
either asserted claim and is referenced only once in the specification—into the
4
construction. The Court finds that, in the context of this case, using elements “a1, a2, and
5
a3” to define “authentication data” would be confusing and overall unhelpful to the jury.
6
Thus, the Court rejects GoDaddy’s proposed construction.
7
At the Markman Hearing, GoDaddy argued that RPost’s proposed construction is
8
“broader” than Judge Gilstrap’s construction because it would allow “authentication
9
data” to include information not authorized by the Patent. Regarding RPost’s proposed
10
construction elements of “content data” and “indicia relating to the destination of the
11
dispatch,” the Court finds no merit in GoDaddy’s argument because both elements are
12
appropriated verbatim from Claims 60 and 82.19
13
Claims 60 and 82 do, however, expressly limit “indicia of a time of successful
14
transmission of the dispatch to the recipient.” Specifically, the “time related indicia must
15
be recorded by an authenticator and provided in a manner resistant to or indicative of
16
tampering by either of the sender and the recipient.” ‘219 Patent col. 2 ll. 64–67, col. 4 ll.
17
27–30 (amended version) (emphasis added). The Court agrees with GoDaddy that this
18
element as currently listed in RPost’s proposal is too broad because it does not account
19
for these limitations.
20
For these reasons, the Court construes “authentication data” as “information that is
21
associated with the contents of the dispatch by generating a representation of at least (1)
22
content data; (2) an indicia of a time of successful transmission of the dispatch to the
23
recipient, said indicia being recorded by an authenticator and provided in a manner that is
24
resistant to or indicative of tampering by either sender or recipient; and (3) an indicia
25
26
27
28
19
The parties’ stipulated construction of “content data” will apply here. See infra
at 26; (Doc. 191-1 at 14).
- 95 -
1
relating to the destination of the dispatch; where the representation is comprised of one or
2
more elements.”20
3
C.
“dispatch record data” (Term No. 3)
1.
4
The Parties’ Positions
5
The parties’ primary dispute over the term “dispatch record data” concerns the
6
breadth of the term. RPost asserts that the term should be broadly interpreted as
7
“information relating to the dispatch.” (Doc. 114 at 16). GoDaddy, on the other hand,
8
proposes a narrower construction: “data recorded by the authenticator during the
9
transmission of the dispatch, which includes at least the time related indicia and the
10
indicia relating to the destination of the dispatch, and which does not include the content
11
data representative of the contents of the dispatch.” (Doc. 117 at 18).
12
In reply, RPost argues that because the four limitations in GoDaddy’s construction
13
are already recited in the claim, incorporating them in the construction would be
14
redundant and unnecessary. (Doc. 119 at 11 (citing various cases)).
2.
15
16
17
18
19
The term “dispatch record data” is disclosed in Claims 60 and 82 and their
dependent claims. Claim 60 states as follows:
60. A method of authenticating a dispatch and contents of the
dispatch successfully transmitted from a sender to a recipient, comprising
the steps of:
20
21
22
Analysis
...
associating, by [an] the authenticator functioning as a non-interested
third party with respect to the sender and the recipient, the content data with
dispatch record data which includes at least said time related indicia and an
23
24
25
26
27
28
20
The Court notes that the fourth claim dispute of the Feldbau Patent is “an indicia
of a time of successful transmission of the dispatch to the recipient.” (Docs. 114 at 16–
17; 117 at 18–19). As set forth below, the Court construes this phrase as “data that
represents the time at which the dispatcher forwarded the dispatch for delivery such that
the recipient may later be able to receive the dispatch and where the data is obtained
without any cooperation from the recipient.”
- 96 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
indicia relating to the destination of the dispatch, to generate authentication
data which authenticate[s] the dispatch and the contents of the dispatch . . . .
‘219 Patent col. 2 ll. 56–col. 3 ll. 7 (amended version) (amendments by Ex Parte
Reexamination Certificate are shown with additions underlined and deletions in bolded
square brackets; italics added for emphasis). Similarly, Claim 82 discloses:
82. An information dispatch system in an electronic communication
network comprising;
...
an authenticator functioning as a non-interested third party with
respect to the sender and the recipient for authenticating the dispatch and
contents of the dispatch transmitted from the source transmitting system to
the destination receiving system, including;
...
(2) means for providing an indicia [relating to] of a time of
successful transmission of the dispatch to the destination receiving system,
said time related indicia being recorded by the authenticator and provided
in a manner resistant to or indicative of tampering by either of the sender
and the recipient;
(3) a processor for associating the content data with dispatch record
data which includes at least said time related indicia and an indicia relating
to the destination of the dispatch, to generate authentication data which
authenticate[s] the dispatch and the contents of the dispatch.
18
Id. col. 4 ll. 4–36 (amendments by Ex Parte Reexamination Certificate are shown with
19
additions underlined and deletions in bolded square brackets; italics added for emphasis).
20
GoDaddy’s proposed construction includes four limitations, requiring dispatch
21
record data to: (1) be recorded by the authenticator during the transmission of the
22
dispatch, include both (2) time related indicia and (3) indicia relating to the destination of
23
the dispatch, and (4) not include the content data representative of the contents of the
24
dispatch. (Doc. 117 at 18). It is clear that the claim language already limits “dispatch
25
record data” by GoDaddy’s second, third, and fourth proposed limitations. On this point,
26
RPost observes that several courts have spurned—on “redundancy” grounds—
27
constructions that incorporate language from the claim itself. (Doc. 119 at 11 (citing
28
- 97 -
1
Interdigital Commuc’ns., Inc. v. ZTE Corp., 2014 WL 3908771, at *1 (D. Del. Aug. 8,
2
2014); Asetek Holdings, Inc. v. Coolit Sys., 2013 WL 6327691, at *4 (N.D. Cal. Dec. 3,
3
2013); Ferring B.V. v. Watson Labs., Inc., 2013 WL 499158, at *7 (D. Nev. Feb. 6,
4
2013)). As noted above, however, the Federal Circuit rejected the robotic application of
5
such a stringent rule. See 01 Communique Lab., Inc. v. LogMeIn, Inc., 687 F.3d 1292,
6
1296 (Fed. Cir. 2012) (“[Plaintiff] argues that because those functions are set forth
7
expressly in the claim, it would be ‘redundant and unnecessary’ to incorporate them into
8
the construction of ‘location facility.’ However, [Plaintiff] has not cited, and we have not
9
discovered, any authority for the proposition that construction of a particular claim term
10
may not incorporate claim language circumscribing the meaning of the term. The claim
11
language makes clear that the location facility in fact does perform the functions in
12
question. The district court correctly incorporated those functions into its claim
13
construction.”). Thus, RPost’s “redundancy” argument, while persuasive, is not binding
14
on the Court.
15
Regarding GoDaddy’s first limitation that dispatch record data must be “recorded
16
by the authenticator during the transmission of the dispatch,” the Court finds that such a
17
limitation is not warranted given the claim language. Specifically, the claim requires only
18
that “time related indicia” be recorded by the authenticator during the transmission of the
19
dispatch. See ‘219 Patent col. 2 ll. 63–67 (amended version). The “recorded by the
20
authenticator” limitation does not relate to all forms of “dispatch record data,” which, as
21
GoDaddy points out, is comprised of at least “time related indicia” and “an indicia
22
relating to the destination of the dispatch.” See id. col. 3 ll. 3–5, col. 4 ll. 31–34. In other
23
words, Claims 60 and 82 do not require that “indicia relating to the destination of the
24
dispatch” be recorded by the authenticator. Consequently, the Court rejects this portion of
25
GoDaddy’s proposed construction.
26
As to GoDaddy’s second and third proposed limitations, the Court concludes that
27
it unnecessary to construe “dispatch record data” as including at least indicia relating to
28
the time and destination of the dispatch. The sentence from which GoDaddy lifts this
- 98 -
1
unambiguous language follows immediately behind the term “dispatch record data” in the
2
claims. See id. col. 3 ll. 3–5, col. 4 ll. 27–30. It is therefore apparent from the claim
3
language that “dispatch record data” must include both indicia.
4
Regarding GoDaddy’s fourth proposed limitation, however, the Court finds that
5
the claim language does not clearly articulate that “dispatch data” and “content data” are
6
distinct types of data. Further, RPost’s proposal is vague because it fails to distinguish
7
between (1) data that concerns the event of the dispatch and (2) data that relates to the
8
contents of the dispatch. The jury would be aided by including this portion of GoDaddy’s
9
proposal in the construction.
10
For these reasons, the Court construes “dispatch record data” as “information
11
relating to the dispatch but not relating to content data representative of the contents of
12
the dispatch.”21
13
D.
14
1.
15
16
17
18
19
20
21
22
23
24
25
26
27
28
“an indicia of time of successful transmission of the dispatch to the
recipient” (Term No. 4)
The Parties’ Positions
The parties’ proposed constructions for the next phrase are again quite similar.
RPost urges the Court to adopt Judge Gilstrap’s construction of “data that represents the
time at which the dispatcher forwarded the dispatch for delivery such that the recipient
may later be able to receive the dispatch and where the data is obtained without any
cooperation from the recipient.” (Doc. 114 at 16–17).
GoDaddy responds that while the majority of Judge Gilstrap’s construction is
correct, two slight modifications should be incorporated: “data that represents the actual
time at which the dispatcher completed transmission of the dispatch for delivery, such
that the recipient may later be able to receive the dispatch and where the data is obtained
without any cooperation from the recipient.” (Doc. 117 at 18–19) (emphasis added).
21
During the Markman Hearing, GoDaddy expressed its concern that “information
relating to the dispatch” is too broad and could include information that it was cloudy at
the time of dispatch. The Court is skeptical that a jury could interpret “information
relating to the dispatch” in a way that yields information about atmospheric conditions.
- 99 -
1
2
3
RPost replies that Judge Gilstrap expressly rejected both of GoDaddy’s proposed
revisions and asks this Court to do the same. (Doc. 119 at 11).
2.
Analysis
4
This phrase is disclosed in Claim 60 as follows:
5
60. A method of authenticating a dispatch and contents of the
dispatch successfully transmitted from a sender to a recipient, comprising
the steps of:
6
7
8
...
10
providing an indicia [relating to] of a time of successful
transmission of the dispatch to the recipient, said time related indicia being
recorded by an authenticator and provided in a manner resistant to or
indicative of tampering by either of the sender and the recipient . . . .
11
‘219 Patent, col. 2 ll. 56–67 (amended version) (amendments by Ex Parte Reexamination
12
Certificate are shown with additions underlined and deletions in bolded square brackets;
13
italics added for emphasis).
9
14
While both of the parties’ proposed constructions are substantially based on Judge
15
Gilstrap’s construction, GoDaddy proposes two alterations. First, GoDaddy argues that
16
the “indicia” must indicate the “actual time” at which the dispatch was forwarded, not
17
merely the “time.” (Doc. 117 at 18–19). Second, GoDaddy asserts that the “indicia” must
18
express when the dispatcher “completed transmission of the dispatch for delivery,” rather
19
than when the dispatcher “forwarded the dispatch for delivery.” (Id.)
20
Judge Gilstrap expressly rejected GoDaddy’s proposed construction of “actual
21
time” and so does this Court. See RMail, 2013 WL 968246, at *21. The Court agrees with
22
Judge Gilstrap that if “time” were construed as “actual time,” such a construction could
23
be read too narrowly by the finder of fact as requiring absolute proof. Id.
24
Moreover, the Court agrees with Judge Gilstrap’s construction of “forwarded the
25
dispatch for delivery.” As Judge Gilstrap explained, the claim language of “successful
26
transmission” is focused on the relevant time at which the “dispatch was released from
27
the control of the non-interested third party.” Id. GoDaddy proposes that “successful
28
transmission” should be construed as “completed transmission,” but offers no compelling
- 100 -
1
reason to justify this revision of Judge Gilstrap’s construction. In any event, the Court
2
finds that construing “successful transmission” as “completed transmission” does little to
3
aid the jury’s understanding of the term.
4
For these reasons, the Court adopts Judge Gilstrap’s construction and construes
5
“an indicia of time of successful transmission of the dispatch to the recipient” to mean
6
“data that represents the time at which the dispatcher forwarded the dispatch for delivery
7
such that the recipient may later be able to receive the dispatch and where the data is
8
obtained without any cooperation from the recipient.”
9
10
E.
“sender” (Term No. 5) and “recipient” (Term No. 6)
1.
The Parties’ Positions
11
RPost requests that the Court adopt Judge Gilstrap’s conclusion that “sender” and
12
“recipient” are readily understandable terms requiring no construction. (Doc. 114 at 17).
13
GoDaddy responds that the terms should be defined as “the computer that
14
originates the message” and “the computer that receives the dispatch at its intended
15
destination,” respectively. (Doc. 117 at 19).
16
In reply, RPost complains that GoDaddy’s arguments conflict with the intrinsic
17
record because such constructions would improperly define the terms with the “same
18
meaning as originating processor and recipient processor from the Tomkow Patents”
19
without justification. (Doc. 119 at 11–12).
20
21
22
23
24
25
26
27
2.
Analysis
The terms “sender” and “recipient” are found in all asserted claims of the Feldbau
Patent. A few examples include:
60. A method of authenticating a dispatch and contents of the
dispatch successfully transmitted from a sender to a recipient . . .
...
securing by said authenticator, at least part of the authentication data
against tampering of the sender and the recipient . . . .
....
28
- 101 -
1
2
3
4
82. An information dispatch system in an electronic communication
network comprising:
a source transmitting system coupled to the electronic
communication network for sending a dispatch from a sender to a recipient;
5
a destination receiving system coupled to the electronic
communication network for receiving the dispatch for the recipient . . .
6
‘219 Patent col. 2 ll. 56–col. 4 ll. 12 (amended version) (amendments by Ex Parte
7
Reexamination Certificate are shown with additions underlined; italics added for
8
emphasis).
9
The Court finds that the terms “sender” and “recipient” have “plain and ordinary
10
meanings.” However, “[a] determination that a claim term ‘needs no construction’ or has
11
a ‘plain and ordinary meaning’ may be inadequate when a term has more than one
12
‘ordinary’ meaning or when reliance on a term’s ‘ordinary’ meaning does not resolve the
13
parties’ dispute.” O2 Micro, 521 F.3d at 1361. GoDaddy correctly posits that “sender”
14
and “recipient” have “ordinary” meanings that include natural persons—a method of
15
transmission not asserted against GoDaddy. (Doc. 117 at 19). For this reason, the Court
16
agrees that construction is necessary because the “plain and ordinary meanings” of these
17
terms “do not resolve the parties’ dispute.” See O2 Micro, 521 F.3d at 1361.
18
The Court now turns to defining the terms. GoDaddy proffers constructions that
19
define “sender” and “recipient” as “computers.” (Id.) RPost replies that such
20
constructions would be unduly narrow as the asserted claims do not limit “sender” and
21
“recipient” to only “computers,” but allow for other types of computerized devices.
22
(Doc. 119 at 11–12). In this regard, the Court agrees with RPost. The asserted claims are
23
not limited to “computers” per se but leave available the use of other forms of
24
computerized devices. See, e.g., ‘219 Patent col. 4 ll. 4–8 (82. An information dispatch
25
system in an electronic communications network comprising: a source transmitting
26
system coupled to the electronic communicating network for sending a dispatch from a
27
sender to a recipient . . . . (amended version) (emphasis added)); id. col. 2 ll. 56–62 (60.
28
A method of authenticating a dispatch and contents of the dispatch successfully
- 102 -
1
transmitted from a sender to a recipient, comprising the steps of: receiving content data
2
representative of the contents of the dispatch originated from the sender and being
3
electrically transmitted to said recipient . . . .” (emphasis added)); ‘219 Patent col. 4 ll. 1–
4
6 (“The present invention encompasses . . . all types of dispatch methods, such as
5
transmission via facsimile machines, modems, computer networks, electronic mail
6
systems and so forth . . . .” (emphasis added)). Thus, the Court rejects GoDaddy’s
7
“computer” proposal.
8
Furthermore, the Court is not persuaded that limiting “sender” as the computerized
9
device that “originates” the dispatch is appropriate. GoDaddy’s proposed construction
10
requires that the “computer” itself “originate” the dispatch, possibly leading to the
11
conclusion that the user interfacing with the computer does not create the message. Thus,
12
the Court’s construction will clarify that “sender” incorporates some level of user
13
intervention to originate a message.
14
Finally, the Court finds that GoDaddy’s proposed limitation “at its intended
15
destination” regarding the “recipient” is vague and requires the jury to engage in
16
unnecessary additional inquiry.
17
For these reasons, the Court construes “sender” as “a combination of (1) the user
18
that caused the computerized device to originate the dispatch and (2) the computerized
19
device itself” and “recipient” as “a combination of (1) the user that the sender intends to
20
receive the message and (2) the computerized device that receives the message.”
21
22
F.
“processor for associating” (Term No. 7)
1.
The Parties’ Positions
23
The parties’ next dispute centers on whether “processor for associating” is subject
24
to means-plus-function (“MPF”) claim construction pursuant to 35 U.S.C. § 112(6).
25
RPost argues that “processor for associating” need not be construed because the term has
26
a plain and ordinary meaning that the jury will be able to understand and apply.
27
(Doc. 114 at 17–18). RPost additionally contends that because the disputed phrase does
28
not include the term “means,” there is a presumption that the patentee did not engage in
- 103 -
1
MPF claiming. (Id.) RPost explains that the phrase recites sufficient structure—a
2
processor—that “is a well-known reference in the electrical arts to a microprocessor or
3
microcontroller and connotes structure.” (Id.) If the Court were to determine that
4
“processor” does require MPF claim construction, RPost asserts that the specification
5
discloses corresponding structures—controller 56 and function executor 102—and
6
algorithms that make the term definite. (Id.; Doc. 119 at 12).
7
GoDaddy responds that despite the absence of the word “means” in the claim,
8
“processor for associating” is still subject to MPF claim construction because it “fails to
9
recite sufficiently definite structure or else recites function without reciting sufficient
10
structure for performing that function.” (Doc. 117 at 19–20). Pursuant to the two-step
11
approach to MPF claim construction, GoDaddy proposes that the claim’s function is
12
“associating the content data with dispatch record data and generating the authentication
13
data.” (Doc. 117 at 15). As to corresponding structure, however, GoDaddy argues the
14
claim is indefinite because if fails to disclose adequate corresponding structure for the
15
claimed functions via an algorithm. (Id.)
2.
16
17
18
19
20
21
22
23
24
25
26
27
28
Legal Standard for Invoking 35 U.S.C. § 112(6)
MPF claim construction is necessary when a patent claim term is drafted in a
manner that invokes 35 U.S.C. § 112(6),22 which states as follows:
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, material, or acts in support thereof, and such claim shall be
construed to cover the corresponding structure, material, or acts described
in the specification and equivalents thereof.
35 U.S.C. § 112(6) (emphasis added). By enacting this statute, “Congress struck a
balance between allowing patentees to express a claim limitation by reciting a function to
22
35 U.S.C. § 112(6) was amended in 2012 to become 35 U.S.C. § 112(f).
However, section f is only applicable to patents issued after September 16, 2012. The
Feldbau Patent was originally filed in 1997, issued in 2001, and was issued an Ex Parte
Reexamination Certificate on June 19, 2012. All asserted claims were modified by the
reexamination in 2012.
- 104 -
1
be performed rather than by reciting structure for performing that function, while placing
2
specific constraints on how such a limitation is to be construed.” Williamson v. Citrix
3
Online, LCC, 792 F.3d 1339, 1347 (Fed. Cir. 2015). Namely, scope of coverage of the
4
claimed functions is limited only to the corresponding structure, materials, or acts
5
described in the specification and equivalents thereof. See Northrop Grumman Corp. v.
6
Intel Corp., 325 F.3d 1346, 1350 (Fed. Cir. 2004).
7
The Federal Circuit has long held that use of the word “means” within a claim is
8
significant in the analysis of whether a claim limitation should be interpreted in
9
accordance with § 112(6). Specifically, there is a “rebuttable presumption” that § 112(6)
10
applies when the claim language includes the word “means,” and a similar “rebuttable
11
presumption” that § 112(6) does not apply when “means” is absent from the claim term.
12
Williamson, 792 F.3d at 1347–49.23 “When a claim term lacks the word ‘means,’ the
13
presumption can be overcome and § 112, para. 6 will apply if the challenger demonstrates
14
that the claim term fails to ‘recite sufficiently definite structure’ or else recites ‘function
15
without reciting sufficient structure for performing that function.’” Id. (quoting Watts v.
16
XL Sys., Inc., 232 F.3d 877, 880 (Fed. Cir. 2000)). The standard to determine “definite
17
structure” is “whether the words of the claim are understood by persons of ordinary skill
18
in the art to have sufficiently definite meaning as the name for structure.” Id. (citing
19
Greenberg v. Ethicon Endo-Surgery, Inc., 91 F.3d 1580, 1583 (Fed. Cir. 1996)).
20
To determine whether the presumption has been rebutted, the Court must consult
21
relevant intrinsic and extrinsic evidence. See Inventio AG v. ThyssenKrupp Elevator Ams.
22
Corp., 649 F.3d 1350, 1357 (Fed. Cir. 2011) (“In cases where the claims do not recite the
23
term ‘means,’ considering intrinsic and extrinsic evidence is usually helpful, as the
24
litigated issue often reduces to whether skilled artisans, after reading the patent, would
25
conclude that a claim limitation is so devoid of structure that the drafter constructively
26
27
28
23
After years of application, Williamson expressly overruled the “strong”
presumption that § 112(6) only applied to claims that included the term “means.”
- 105 -
1
engaged in [MPF] claiming.”); Media Rights Techs., Inc. v. Capital One Fin. Corp., 800
2
F.3d 1366, 1372 n.2 (Fed. Cir. 2015) (noting that courts must consider the entire intrinsic
3
record when assessing whether a claim term invokes § 112(6)).
4
3.
§ 112(6) Analysis
5
The term “processor for associating” is disclosed in Claim 82 as follows:
6
82. An information dispatch system in an electronic communication
network comprising;
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
...
An authenticator functioning as a non-interested third party with
respect to the sender and the recipient for authenticating the dispatch and
contents of the dispatch transmitted from the source transmitting system to
the destination receiving system, including;
(1) an input unit coupled to the communication network or to the
source transmitting system for receiving content data representative of the
contents of the dispatch being electronically transmitted to said destination
receiving system, and a destination of the dispatch;
(2) means for providing an indicia [relating to] of a time of
successful transmission of the dispatch to the destination receiving system,
said time related indicia being recorded by the authenticator and provided
in a manner resistant to or indicative of tampering by either of the sender
and the recipient;
(3) a processor for associating the content data with dispatch record
data which includes at least said time related indicia and an indicia relating
to the destination of the dispatch, to generate authentication data which
authenticate[s] the dispatch and the contents of the dispatch; and
(4) means for securing at least part of the authentication data against
tampering of the sender and the recipient;
wherein the processor is combined with the means for securing.
23
‘219 Patent col. 4 ll. 4–41 (amended version) (amendments by Ex Parte Reexamination
24
Certificate are shown with additions underlined and deletions in bolded square brackets;
25
italics added for emphasis).
26
To begin, the term “processor for associating” does not include the word “means.”
27
Therefore, there is a rebuttable presumption that the term is not subject to § 112(6). The
28
question before the Court is whether that presumption has been overcome. Specifically,
- 106 -
1
the Court must determine whether the term “processor” (1) fails to “recite sufficiently
2
definite structure” or (2) recites “function without reciting sufficient structure for
3
performing that function.” Williamson, 792 F.3d at 1349 (citations omitted).
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
a.
Whether
“Processor
for
Sufficiently Definite Structure
Associating”
Recites
RPost argues that “processor” has a sufficiently definite meaning because the term
“is a well-known reference in the electrical arts to a microprocessor or microcontroller
and connotes structure.” (Doc. 114 at 17–18). GoDaddy’s argument concentrates not on
the initial inquiry of whether the term itself recites sufficient structure to avert § 112(6),
but assumes that § 112(6) applies and explains that computer-related claim limitations
“must include the algorithm needed to transform the general purpose computer or
processor disclosed in the specification into the special purpose computer programmed to
perform the disclosed algorithm—or else be indefinite.” (Doc. 117 at 19–20).
In support of its argument, GoDaddy relies on Aristocrat Techs. Austl. Pty Ltd. v.
Int’l Game Tech., 521 F.3d 1328 (Fed. Cir. 2008). In Aristocrat, however, the disputed
claim included the term “control means,” which both parties agreed invoked § 112(6).
521 F.3d at 1331. The court applied traditional MPF claim construction principals,
requiring the scope of the claim limitation to be defined by the structure disclosed in the
specification plus any equivalents of that structure. See id. The patent-holder argued the
structure corresponding to the recited functions was a standard microprocessor-based
gaming machine with appropriate programming. See id. The Federal Circuit held,
In cases involving a computer-implemented invention in which the inventor
has invoked means-plus-function claiming, this court has consistently
required that the structure disclosed in the specification be more than
simply a general purpose computer or microprocessor. . . . For a patentee to
claim a means for performing a particular function and then to disclose
only a general purpose computer as the structure designed to perform that
function amounts to pure functional claiming.
Id. at 1333 (emphasis added). GoDaddy’s argument is based on the reverse legal theory,
arguing that if “processor” is an insufficient structure to define the scope of an MPF
28
- 107 -
1
limitation, it cannot describe sufficient structure when recited directly in a claim
2
limitation itself. See (Doc. 117 at 19–20).
3
The Court is not persuaded that Aristocrat is applicable or binding in this case.
4
Initially, Aristocrat analyzed claim language that expressly used the term “means,” and as
5
such, there was a presumption that MPF claim limitations were at issue. In fact, the
6
parties stipulated that the term invoked § 112(6). The Aristocrat rule that GoDaddy
7
argues should apply here was therefore derived from a determination as to whether
8
sufficient structure was disclosed in the specification so as to avoid a finding of
9
indefiniteness. GoDaddy is effectively treating as equivalent the standard used to prove
10
sufficient structure to avoid MPF treatment initially, with the standard used to identify
11
corresponding structure in the specification when MPF construction is necessary.
12
GoDaddy does not cite any cases that apply Aristocrat in this manner, and other courts
13
have declined to do so. See eWinWin, Inc. v. Groupon, Inc., 2011 WL 6012194, at *14–
14
15 (M.D. Fla. Sept. 5, 2011) (declining to apply Aristocrat to find that “computer code”
15
was written as an MPF limitation, and noting that “the law on this issue goes both ways,
16
and the Federal Circuit has not had an opportunity to take a clear stance on facts similar
17
to those in the instant case”); Markem–Imaje Corp. v. Zipher Ltd., 2011 WL 5837087, at
18
*4 n.7 (D.N.H. Nov. 21, 2011) (“The structural disclosure required in the specification
19
when a party chooses to employ [MPF] claiming is not the same structural disclosure
20
required to avoid [MPF] treatment.”); Chamberlain Grp., Inc. v. Lear Corp., 756 F. Supp.
21
2d 938, 977 (N.D. Ill. 2010) (noting that Aristocrat only applies when § 112(6) has been
22
invoked).
23
For the first inquiry of the Williamson analysis, the Federal Circuit only requires—
24
contrary to GoDaddy’s argument—that the claim recite some structure to avoid § 112(6)
25
and has repeatedly rejected as “unduly restrictive” the argument that “specific structure”
26
is necessary. See Lighting World, 382 F.3d 1354, 1359–60 (Fed. Cir. 2004), overruled on
27
other grounds by Williamson, 792 F.3d 1339. For example, the Federal Circuit explained:
28
- 108 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Implicit in [expert witness’s] statement is the premise that in order to be
regarded as structural for purposes of section 112 ¶ 6, a claim limitation
must identify a specific structure and not use a generic term that includes a
wide variety of structures. The district court adopted that view explicitly
when it held that the claim language “connector assembly being pivotally
connected to said pair of adjacent support members” was not structural
because “it would cover every conceivable structure that could connect two
elements and pivot.”
That approach is unduly restrictive. In considering whether a claim
term recites sufficient structure to avoid application of section 112 ¶ 6, we
have not required the claim term to denote a specific structure. Instead, we
have held that it is sufficient if the claim term is used in common parlance
or by persons of skill in the pertinent art to designate structure, even if the
term covers a broad class of structures and even if the term identifies the
structures by their function.
Id. (citing Greenberg v. Ethicon Endo–Surgery, Inc., 91 F.3d 1580, 1583 (Fed. Cir.
1996); Apex Inc. v. Raritan Comput., Inc., 325 F.3d 1364, 1372 (Fed. Cir. 2003); CCS
Fitness, Inc. v. Brunswick Corp., 288 F.3d 1359, 1369 (Fed. Cir. 2002); Watts, 232 F.3d
at 880; Personalized Media Commc’ns, LLC v. Int’l Trade Comm’n, 161 F.3d 696, 704–
05 (Fed. Cir. 1998)) (emphasis added). While the term “processor” may not bring to mind
a specific structure, that point is not dispositive for this first inquiry. See Personalized
Media Commc’ns, 161 F.3d at 704 (“[N]either the fact that a ‘detector’ is defined in
terms of its function, nor the fact that the term ‘detector’ does not connote a precise
physical structure in the minds of those of skill in the art detracts from the definiteness of
structure.”). What is important is whether “processor” is a term that is understood to
describe structure, as opposed to a term that is simply a nonce word not recognized as the
name of structure and merely substitutes for “means for.” Id.
In this case, the Court finds that “processor,” albeit a term that might cover a
broad class of structures, designates at least some structure. For example, one technical
dictionary defines “processor” as “a device that (a) executes instructions, usually
automatically and under computer program control, and (b) consists of at least an
instruction control unit and an arithmetic unit.” Martin H. Weik, Fiber Optics Standard
28
- 109 -
1
Dictionary 789 (3d ed. 1997); see also American Heritage Dictionary of the English
2
Language 1398 (4th ed. 2006) (defining “processor” as “2. Computer Science a. A
3
computer. b. A central processing unit. c. A program that translates another program into
4
a form acceptable by the computer being used.”); Philip E. Margolis, Random House
5
Webster’s Computer & Internet Dictionary 448 (3d ed. 1999) (defining “processor” as
6
“Short for microprocessor or CPU”); Lighting World, 382 F.3d at 1361 (consulting
7
dictionary definitions to determine whether “connector” has a reasonably well-
8
understood meaning as a name for structure); Linear Tech., 379 F.3d at 1320 (finding that
9
technical dictionary definitions aid determination of whether a claim term is structural).
10
This conclusion is buttressed by the intrinsic record which discloses structural features of
11
the processor. See ‘219 Patent col. 13 ll. 19–27.
12
The Court agrees with RPost that one of ordinary skill in the art would understand
13
that “processor” encompasses a microprocessor or microcontroller—structural terms.
14
While “processor” “does not connote a precise physical structure in the minds of those of
15
skill in the art[, that does not] detract[] from the definiteness of structure.” Personalized
16
Media Commc’ns, 161 F.3d at 704 (citing Greenberg, 91 F.3d at 1583).
18
Whether “Processor for Associating” Recites Function
without Sufficient Structure for Performing that
Function
19
Although the Court concludes that the term “processor” connotes at least some
20
structure, this does not end the Williamson analysis. The Federal Circuit also allows a
21
challenger to overcome the presumption against application of § 112(6) if the claim
22
recites “function without reciting sufficient structure for performing that function.”
23
Williamson, 792 F.3d at 1349 (quoting Watts, 232 F.3d at 880). Here, Claim 82 provides
24
that the “processor” is “for associating the content data with dispatch record data which
25
includes at least said time related indicia and an indicia relating to the destination of the
26
dispatch, to generate authentication data.” ‘219 Patent col. 4 ll. 31–36 (amended version).
17
b.
27
28
- 110 -
1
Thus, the Court must determine whether “processor” connotes “sufficient structure for
2
performing” the claimed associating and generating functions.
3
The Court first reviews how one skilled in the art would understand “processor” as
4
used in Claim 82. Based on a review of dictionary definitions, the Court concludes that a
5
skilled artisan would not recognize “processor” as a name of a sufficiently definite
6
structure for “associating” two distinct types of data in order to “generate” a third class of
7
data. Rather, one skilled in the art would understand “processor” to mean a general
8
purpose computer, a central processing unit (“CPU”), or a program that translates another
9
program into a form acceptable by the computer being used. See American Heritage
10
Dictionary of the English Language 1398.
11
Of course, if the functions performed by the processor are functions typically
12
found in a commercially available off-the-shelf processor, then a skilled artisan might
13
understand the term “processor” to provide sufficient structure for performing those
14
functions. See In re Katz Interactive Call Processing Patent Litig. (“Katz”), 639 F.3d
15
1303, 1316 (Fed. Cir. 2011) (holding that functions such as “processing,” “receiving,”
16
and “storing” that can be achieved by any general purpose computer without special
17
programming do not require disclosure of more structure than the general purpose
18
processor that performs those functions). In this case, however, the Court concludes that
19
“associating” two sets of data in order to “generate” a third set of data is not a typical
20
function found in a general purpose processor and requires additional programming of the
21
processor to implement. Accordingly, the claimed “processor” alone is not sufficient
22
structure to perform the functions in Claim 82.
23
Finally, the term “processor” is different from claim terms “circuit” and
24
“circuitry,” which the Federal Circuit has found to denote sufficiently definite structure to
25
avoid application of § 112(6). See Mass. Inst. of Tech. & Elec. for Imaging, Inc. v.
26
Abacus Software (“MIT”), 462 F.3d 1344, 1354–56 (Fed. Cir. 2006); Linear Tech., 379
27
F.3d at 1320–21; Apex, 325 F.3d at 1374. These decisions hold that the term “circuit”
28
coupled with a description in the claims of the circuit’s operation generally conveys the
- 111 -
1
structural arrangement of the circuit’s components. See MIT, 462 F.3d at 1355; Linear
2
Tech., 379 F.3d at 1320; Apex, 325 F.3d at 1373. In this case, however, the claimed
3
“processor” and other claim language does not convey to a skilled artisan anything about
4
the internal components, structure, or specific operation of the processor.
5
For these reasons, the Court concludes that the term “processor” as used in Claim
6
82 is a term that would not be understood by an ordinarily skilled artisan as having
7
sufficient structure for performing the recited functions of “associating the content data
8
with dispatch record data . . . to generate the authentication data” and therefore invokes
9
the
application
of
§
112(6).
See
Ex
parte
Smith,
No.
2012-007631,
10
http://www.uspto.gov/sites/default/files/ip/boards/bpai/decisions/inform/ex_parte_smith_
11
fd2012007631.pdf (P.T.A.B. Mar. 14, 2013) (holding that the claim “a processor . . .
12
programmed to . . . generate an opinion timeline” invoked § 112(6) because the claim
13
recited function without sufficient structure to perform the function).
4.
14
Legal Standard for MPF Claim Construction
15
When § 112(6) applies to a claim, the Court follows a two-step construction
16
approach. First, the Court identifies the particular claimed functions using traditional
17
tools of claim construction. See Med. Instrumentation & Diagnostics Corp. v. Elekta AB,
18
344 F.3d 1205, 1210 (Fed. Cir. 2003); Omega Eng’g, 334 F.3d at 1330. The Court may
19
not adopt functions that are different from those explicitly recited in the claim language.
20
See Cardiac Pacemakers, Inc. v. St. Jude Med., Inc., 296 F.3d 1106, 1113 (Fed. Cir.
21
2002).
22
Second, the Court reviews the specification and identifies the corresponding
23
structure that performs those functions. See Elekta, 344 F.3d at 1210. A disclosed
24
structure is “‘corresponding’ . . . only if the specification or prosecution history clearly
25
links or associates that structure to the function recited in the claim,” id. (quotation
26
omitted), and only if the structure can perform the claimed function, see Cardiac
27
Pacemakers, 296 F.3d at 1113. These inquiries are made from the perspective of a person
28
of ordinary skill in the art. See Cardiac Pacemakers, 296 F.3d at 1113.
- 112 -
1
To avoid purely functional claiming in cases involving computer-implemented
2
inventions, the Federal Circuit has “consistently required that the structure disclosed in
3
the specification be more than simply a general purpose computer or microprocessor.”
4
Aristocrat, 521 F.3d at 1333. “Because general purpose computers can be programmed to
5
perform very different tasks in very different ways, simply disclosing a computer as the
6
structure designated to perform a particular function does not limit the scope of the claim
7
to ‘the corresponding structure, material, or acts’ that perform the function, as required by
8
section 112 paragraph 6.” Id. Thus, for a computer or processor-implemented claim
9
limitation interpreted under § 112(6), the corresponding structure must disclose the
10
algorithm needed to transform the disclosed general purpose computer or processor into
11
the special purpose computer. Id. Failure to disclose the corresponding algorithm for a
12
computer-implemented MPF term renders the claim indefinite. Id. at 1337–38.
13
An algorithm is a “sequence of computational steps to follow.” Ibormeith IP, LLC
14
v. Mercedes-Benz USA, LLC, 732 F.3d 1376, 1379 (Fed. Cir. 2013) (citations omitted).
15
“For a claim to be definite, a recited algorithm . . . need not be so particularized as to
16
eliminate the need for any implementation choices by a skilled artisan; but it must be
17
sufficiently defined to render the bounds of the claim—declared by section 112(6) to
18
cover the particular structure and its equivalents—understandable by the implementer.”
19
Id. (citing AllVoice Computing PLC v. Nuance Commc’ns, Inc., 504 F.3d 1236, 1245–46
20
(Fed. Cir. 2007)). An algorithm may be expressed as a mathematical formula, in prose, as
21
a flow chart, or in any other manner that provides sufficient structure. Noah Sys., Inc. v.
22
Intuit Inc., 675 F.3d 1302, 1312 (Fed. Cir. 2012) (citing Finisar Corp. v. DirecTV Grp.,
23
Inc., 523 F.3d 1323, 1340 (Fed. Cir. 2008)). Nonetheless, the purported algorithm cannot
24
“merely provide[] functional language” and must provide a “step-by-step procedure” for
25
accomplishing the claimed function. Ergo Licensing, 673 F.3d at 1365. Further, “[i]t is
26
well settled that simply disclosing software, however, without providing some detail
27
about the means to accomplish the function, is not enough.” Function Media, L.L.C. v.
28
Google, Inc., 708 F.3d 1310, 1318 (Fed. Cir. 2013) (quotations omitted).
- 113 -
1
Finally, in a means-plus-function claim “in which the disclosed structure is a
2
computer, or microprocessor, programmed to carry out an algorithm, the disclosed
3
structure is not the general purpose computer, but rather the special purpose computer
4
programmed to perform the disclosed algorithm.” WMS Gaming, 184 F.3d at 1349. Thus,
5
“the corresponding structure for a § 112 ¶ 6 claim for a computer-implemented function
6
is the algorithm disclosed in the specification.” Harris Corp. v. Ericsson Inc., 417 F.3d
7
1241, 1249 (Fed Cir. 2005).
8
9
5.
MPF Claim Construction
a.
Function
10
The Court finds that GoDaddy’s functionality proposal is supported by the claim
11
language and accurately recites the function of the processor. See ‘219 Patent col. 4 ll.
12
31–36 (amended version). Thus, the Court construes the claim’s function as “associating
13
the content data with dispatch record data and generating the authentication data.”
14
b.
Corresponding Structure
15
In its Opening Brief, RPost argues that the specification discloses two
16
corresponding structures: “controller 56” and “function executor 102, which may be a
17
Microchip Technology Inc.’s PIC16C5x series EPROM-based micro-controller.”
18
(Doc. 114 at 18). GoDaddy responds that the specification does not disclose a
19
corresponding structure because no algorithm is provided that transforms the general
20
purpose processor into a special purpose processor that can perform the claimed
21
functions. (Doc. 117 at 19–20). Thus, GoDaddy contends that the claim is indefinite. (Id.)
22
RPost replies that the specification “discloses numerous mathematical formulas
23
that may be used by function generator 102 to perform the claimed ‘associating.’”
24
(Doc. 119 at 12 (citing ‘219 Patent col. 10 ll. 13–col. 13 ll. 7)).
25
Initially, the Court concludes that an algorithm must be disclosed in the
26
specification. The processor’s claimed functions are to “associate” data to “generate”
27
authentication data. ‘219 Patent col. 4 ll. 31–36 (amended version). As discussed above,
28
these functions cannot be performed solely by a general purpose computer or processor,
- 114 -
1
but require a special purpose computer. See EON Corp. IP Holdings LLC v. AT&T
2
Mobility LLC, 785 F.3d 616, 623 (Fed. Cir. 2015) (“A microprocessor or general purpose
3
computer lends sufficient structure only to basic functions of a microprocessor. All other
4
computer-implemented functions require disclosure of an algorithm.”). Accordingly, the
5
algorithm that transforms the general purpose processor into a special purpose processor
6
that performs the claimed function is required. See Aristocrat, 521 F.3d at 1333.
7
The relevant portions of the specification disclose:
8
The controller 56 associates the information 60 and the dispatch
information, by storing them in storage unit 54 and by associating link
information with the stored authentication-information, for example, in the
form of a unique dispatch identifier such as a sequential dispatch number.
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
‘219 Patent col. 7 ll. 59–64.
An efficient method for associating a plurality of information
elements is by associating a digital representation thereof using a method
referred to herein as “mathematical association”. A digital representation of
an information element can be considered as a number, for example as the
element’s standard binary, hexadecimal or other base representation. Using
mathematical association, rather than maintaining the information elements
(numbers) themselves, it is sufficient to maintain the results (also numbers)
of one or more functions which are applied to one or more of these
information elements. (These results are sometimes referred to as
“message-digests”, “hash-values” or “digital-signatures”). More formally, if
A is a set of information elements, and F is the mathematical association
function, then the set B of information elements is obtained as the result of
applying the function F to the set A of information elements, i.e. B=F(A).
Preferably, the function F is selected such that a fraudulent attempt
to change the elements of the set A, or an attempt to claim that a set A’
which comprises different elements is the original set, can be readily
detected by comparing the result B’ obtained by applying the function F to
the set A’, to the original result B, i.e., by checking if F(A’)=F(A).
It would be advantageous to select the function according to a
cryptographic schemes. Encryption and digital envelope functions can
provide for secure data interchange. Digital signatures can provide for
accurate and reliable verification of both the signature generator and the
data. One-way hash functions provides for security, and can reduce the size
of the generated signatures while still enable verification of the original
28
- 115 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
data used to generate these signatures. Utilizing combinations of
cryptographic schemes can optimize particular implementations.
Various function classes of various degrees of complexity can be
used for mathematical association purposes in accordance with various
embodiments of the present invention. Furthermore, the function F and/or
the result B can be kept secret and unknown in general, and to interested
parties such as the sender or the recipient in particular. However, even if the
function F and/or the result B are known, the task of finding a meaningful
different set A’ such that B=F(A’) is mostly very difficult even for
relatively simple functions, not to mention for more complex ones.
A special class of functions most suitable for the purposes of the
present invention is the class of functions having the property that given the
result B=F(A), it is exceptionally difficult to find a second set A’ such that
applying the function F to the second set A’ will yield the same result B.
The term “exceptionally difficult” refers herein to the fact that although
many different such sets A’ may exist, it is so difficult to find even one of
them (sometimes even to find the set A itself) that it is practically
infeasible. In fact, the functions of this class “hide” the elements they are
applied to, (and sometimes the elements even cannot be reconstructed) and
therefore this class is referred to herein as “the Hiding Class”.
....
Few well known and widely used functions of the Hiding class are
encryption functions (e.g., the RSA [1.06] or the DES [1.01] algorithms)
and Cyclic-Redundancy-Check [3] (C.R.C.) functions (e.g., the C.R.C-32
function). While C.R.C functions are generally used in applications
requiring verification as to the integrity of an arbitrarily long block of data,
encryption is used to maintain the original data elements, though in
different, cryptic representation. Encryption functions convert the
information elements into one or more cryptic data blocks using one key,
while enabling their reconstruction by providing a matching (same or
different) key. Other well known members of this class of functions in the
prior art are compression functions (e.g., the Lempel-Ziv 1977 [5] and 1978
algorithms), one-way hash functions [1.03] (e.g., the MD4 [4], and MD5
[1.04] algorithms), and MACs [1.13].
Since for authentication purposes there is no need to maintain the
original information elements, the use of encryption functions (which
normally maintain the information though in a cryptic representation) may
be inefficient. One-way hash functions (and other functions of the Hiding
Class), on the other hand, maintain a small sized result value, but the
information elements from which the result has been produced are secured,
- 116 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
i.e., cannot be reconstructed therefrom. It would be more advantageous, for
example, to apply a one-way hash function to the union of all the
information elements, i.e., to a bit-string, where the leftmost bit is the
leftmost bit of the first element, and the rightmost bit is the rightmost bit of
the last element. This produces a cryptic and secure result, as described
hereinabove. Furthermore, one-way hash functions can be computed
relatively quickly and easily.
Generally and more formally, the result B is a set of one or more
information elements b1, . . . , bm, where each element bi (which itself can
comprise one or more information elements) is the result of applying a
(possibly different) function Fi to a subset Si of a set A which comprises
one or more information elements a1, . . . , an, where the various subsets Si
are not necessarily disjoint or different, each subset Si includes at least a
portion of one or more (or even all) of the electronic information elements
of the set A, and where each function Fi can comprise one or more
functions (i.e., Fi can be the composition of functions). Preferably, the
functions Fi are members of the Hiding Class. The elements of such a
subset Si are considered to be mathematically associated.
Assuming that the set A comprises five information elements a1, a2,
a3, a4, a5, a few examples of mathematical association function Fi and their
result set B follow: (the UNION function is denoted as U(x1, . . . , xk),
Which is an information element comprising a bit-string, where the left
most bit is the leftmost bit of the element x1, and the rightmost bit is the
rightmost bit of the element xk.)
(a) single element result set B
b1=F1(S1)=F1(a1,a4,a5)=a1/(a4+a5+1)
19
b1=F1(S1)=F1(a1,a3,a4)=ENCRYPT(U(a1,a3,a4))
20
b1=F1(S1)=F1(a1,a2,a3,a4,a5)=MD5(U(a1,a2,a3,a4,a5))*
C.R.C.(a3)mod5933333
21
22
23
24
25
26
27
b1=F1(S1)=F1(a1,a2,a3,a4,a5)=C.R.C.(ENCRYPT(U(a1,a2)),
COMPRESS(U(a2,a3,a4)),a1,a5)
b1=F1(S1)=F1(a1,a2,a3,a4,a5)=U(a1,a2,a3,a4,a5)modp(where
p is a large Prime number)
b1=F1(S1)=F1(a1,a2,a3,a4,a5)=ENCRYPT(MD5(U(a1,a2,
a3,a4,a5)))
(b) multi-element result set B
B=[C.R.C.(U(a1,a3)),a2/(a1+1),ENCRYPT(a5)]
28
- 117 -
1
b1=F1(S1)=F1(a1,a3)=C.R.C.(a1,a3)
2
b2=F2(S2)=F2(a1,a2)=a2/(a1+1)
3
b3=F3(S3)=F3(a5)=ENCRYPT(a5)
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
The elements of two or more (not necessarily disjoint) subsets of set
A can be associated with each other by associating the elements of the
result set B which correspond to these subsets, either mathematically, or by
non-mathematical methods, as described hereinabove. Furthermore, if there
is a subset of elements of set A to which no function has been applied, these
elements may be associated with the elements of the result set B, again
either mathematically or by non-mathematical methods.
Moreover, the elements of two or more subsets of the set A can be
associated with each other by associating the elements of each of these
subsets with a common subset comprising one or more elements of the set
A, where this common subset uniquely relates to the specific dispatch. This
type of association is referred to herein as “indirect association”, and the
elements of this common subset are referred to herein as “link elements”. A
link element can be for example a unique dispatch number, or the subset
comprising the time indication and a machine serial number, etc.
For example, assuming that the element a2 of the above set A
uniquely relates to the dispatch, the following function generates a multielement result set B:
B=[b1,b2,b3]=[ENCRYPT(a1,a2), COMPRESS(a2,a3,a4), a2+a5]
where the subsets Si include the following elements: S1=[a1,a2],
S2=[a2,a3,a4] and S3=[a2,a5]. The elements of each subset are
mathematically associated. Since all of these subsets include the common
link-element a2, all their elements (in this case all the elements of the set A)
are associated with each other.
Id. col. 10 ll. 13–col. 13 ll. 7 (brackets in original; italics added for emphasis).
Reference is now made to FIG. 4 which is a block diagram that
illustrates an authenticator 100, constructed and operative in accordance
with a preferred embodiment of the present invention. The authenticator
100 comprises a secure time generator 104, a storage device 106 and a
function executor 102 which has means for inputting the following
information elements: the transmitted information, the destination address,
a time indication generated by the secure time generator 104, and a dispatch
completion indication. Optionally, additional information elements can be
provided as well.
28
- 118 -
1
2
3
4
5
6
The function executor 102 can be for example a Microchip
Technology Inc.’s PIC16C5x series EPROM-based micro-controller, and
the input means can be for example an I/O port, a serial, parallel or disk
interface. The function executor 102 is capable of executing a function F on
at least one, and preferably on the union of all of the input elements, and of
generating a result information element which is provided to a storage
device 106, and optionally to an output device 108, such as a printing
device.
13
Preferably, the function F is a member of the Hiding Class, and is
kept unknown at least to any interested party, by the function executor 102.
This can be achieved for example by enabling the code protection feature of
the PIC16C5x series microcontroller. Alternatively, a MAC [1.13] such as
a one-way hash function MAC can be used where secret codes, keys and
data relating to the function can be for example stored in a shielded
memory device which is automatically erased if the authenticator 100 is
tampered with. Also, preferably the storage device 106 is a WORM device,
such as a PROM. Preferably, a different function is used for each device
employing the function F. This can be achieved for example by using
different keys or codes with each function.
14
Id. col. 13 ll. 8–41 (brackets in original; italics added for emphasis). RPost argues that the
15
specification discloses two embodiments that perform the claimed functions:
16
(1) controller 56 and (2) function executor 102, which may be a Microchip Technology
17
Inc.’s PIC16C5x series EPROM-based micro-controller. (Doc. 114 at 17–18).
7
8
9
10
11
12
18
Regarding controller 56, the Court concludes that the specification does not
19
disclose a sufficient algorithm for this embodiment. While an algorithm to perform the
20
claimed function of “associating” has likely been disclosed for this embodiment, no
21
algorithm has been disclosed for the second function of “generating.” See ‘219 Patent col.
22
7 ll. 59–64. Specifically, the portion of the specification discussing controller 56 only
23
speaks to “associating” data, but never discusses how controller 56 is to “generate” data.
24
Nor does the specification relate controller 56 to the algorithms that function
25
executor 102 has the capacity to perform. Because the algorithm must disclose how
26
controller 56 performs all claimed functions, this embodiment does not disclose sufficient
27
corresponding structure. See Media Rights, 800 F.3d at 1374 (“Where there are multiple
28
- 119 -
1
claimed functions . . . the patentee must disclose adequate corresponding structure to
2
perform all of the claimed functions.” (citing Noah, 675 F.3d at 1318–19)).
3
As to function executor 102, however, the Court finds that the two methods of
4
associating and generating data disclosed in the specification—“mathematical
5
association” and “indirect association”—adequately set forth mathematical algorithms
6
that perform the claim’s functions of “associating” and “generating.” See Noah, 675 F.3d
7
at 1312 (“The specification can express the algorithm ‘in any understandable terms
8
including as a mathematical formula, in prose, or as a flow chart, or in any other manner
9
that provides sufficient structure.’” (quoting Finisar, 523 F.3d at 1340)). Although the
10
specification describes the associating and generating processes in lengthy detail, the
11
algorithm for performing the two functions can be boiled down to the following section
12
of the specification:
13
14
15
16
More formally, if A is a set of information elements, and F is the
mathematical association function, then the set B of information elements is
obtained as the result of applying the function F to the set A of information
elements, i.e. B=F(A).
‘219 Patent col. 10 ll. 25–29.
17
Specifically to Claim 82, the processor “associates” the content data with dispatch
18
record data (set A) by applying mathematical association function (F) to “generate”
19
authentication data (set B). The same foundational equation (i.e., B=F(A)) is used by both
20
“mathematical association” and “indirect association,” and both methods expound on the
21
algorithm See id. col. 10 ll. 13–29; id. col. 12 ll. 55–col. 13 ll. 7. The specification also
22
discloses various association functions, such as encryption and C.R.C. functions, which
23
need not be recited in full here. Rather, for purposes of providing a “step-by-step
24
procedure” that a skilled artisan would understand constitutes sufficient structure to
25
perform the claimed functions, the recited mathematical algorithm satisfies that
26
requirement. See EON Corp. IP Holdings, 785 F.3d at 624 (citing Noah, 675 F.3d at
27
1313); Ibormeith, 732 F.3d at 1379 (“For a claim to be definite, a recited algorithm . . .
28
need not be so particularized as to eliminate the need for any implementation choices by
- 120 -
1
a skilled artisan; but it must be sufficiently defined to render the bounds of the claim—
2
declared by section 112(6) to cover the particular structure and its equivalents—
3
understandable by the implementer.” (citation omitted)).24
4
Consequently, the Court rejects GoDaddy’s argument that the claim is indefinite
5
for lack of corresponding structure, see Cardiac Pacemakers, 296 F.3d at 1113–14 (Fed.
6
Cir. 2002) (“Alternative embodiments may disclose different corresponding structure,
7
and the claim is valid even if only one embodiment discloses corresponding structure.”
8
(citation omitted)), and construes the corresponding structure for this claim term as “a
9
function executor 102, which may be a Microchip Technology Inc.’s PIC16C5x series
10
EPROM-based micro-controller, that associates a set of information elements (“A”) by
11
applying an association function (“F”) to generate another set of information elements
12
(“B”), i.e., B=F(A); and its equivalents.” See Ericsson, 417 F.3d at 1249 (“[T]he
13
corresponding structure for a § 112 ¶ 6 claim for a computer-implemented function is the
14
algorithm disclosed in the specification.”).
6.
15
Conclusion
16
For the reasons set forth above, the Court finds that “processor for associating” is
17
subject to § 112(6) thereby compelling MPF claim construction. The Court construes the
18
claim’s function to be: “associating the content data with dispatch record data and
19
generating the authentication data.” As to structure, the Court construes the claim’s
20
corresponding structure as: “a function executor 102, which may be a Microchip
21
Technology Inc.’s PIC16C5x series EPROM-based micro-controller, that associates a set
22
of information elements (“A”) by applying an association function (“F”) to generate
23
another set of information elements (“B”), i.e., B=F(A); and its equivalents.”
24
25
26
27
28
24
GoDaddy argued during the Markman Hearing that the equation B=F(A) is
merely a generic math function taught in first year calculus. That argument—whether
true or not—is inconsequential. The Federal Circuit only requires the inventor to disclose
an algorithm that can perform the claimed functions. The algorithm as set forth in the
Feldbau Patent’s specification satisfies that requirement.
- 121 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
G.
“means for providing an indicia of a time of successful transmission of
the dispatch to the destination receiving system, said time related
indicia being recorded by the authenticator and provided in a manner
resistant to or indicative of tampering by either of the sender and the
recipient” (Term No. 8)
1.
The Parties’ Positions
The parties agree that this phrase is subject to MPF claim construction pursuant to
§ 112(6) and stipulate as to the claim’s functionality but dispute the corresponding
structure. Namely, RPost asks the Court to adopt the corresponding structure as found by
Judge Gilstrap: “(1) internal clock 50 (2) communications network server (3) Secure time
generator 104 (4) Digital Notary System (DNS); and their equivalents.” (Doc. 114 at 18).
GoDaddy contends the corresponding structure should be “a secure clock internal
to the authenticator or a time stamping service such as the Digital Notary System (DNS)
external to the authenticator that is secured from being set or modified by an interested
party such as the sender.” (Doc. 117 at 20). GoDaddy explains that “it agrees with
RPost’s construction with one exception: the time generator must be secured from being
set or modified by an interested party such as the sender.” (Id.) GoDaddy argues this
limitation is “expressly recited” in the specification as part of the structure for providing
the time source indicia. (Id.)
RPost replies that GoDaddy’s construction excludes two express corresponding
structures from the specification: communications network server and secure time
generator 104. (Doc. 119 at 12). RPost further argues that GoDaddy’s proposal limiting
the time generator as “secured from being set or modified by an interested party such as
the sender” is flawed because that limitation is “only mentioned in the specification
describing the communication network server, not the other three structures.” (Id.)
2.
Legal Standard
Because this claim is subject to § 112(6), the Court will apply the two step
approach for MPF claim construction as set forth in Term No. 7.
28
- 122 -
1
3.
Analysis
2
This disputed phrase is found in Claim 82 as follows:
3
82. An information dispatch system in an electronic communication
network comprising;
4
5
6
7
8
9
...
an authenticator functioning as a non-interested third party with
respect to the sender and the recipient for authenticating the dispatch and
contents of the dispatch transmitted from the source transmitting system to
the destination receiving system, including;
...
12
(2) means for providing an indicia [relating to] of a time of
successful transmission of the dispatch to the destination receiving system,
said time related indicia being recorded by the authenticator and provided
in a manner resistant to or indicative of tampering by either of the sender
and the recipient . . . .
13
‘219 Patent col. 4 ll. 4–30 (amended version) (amendments by Ex Parte Reexamination
14
Certificate are shown with additions underlined and deletions in bolded square brackets;
15
italics added for emphasis).
10
11
16
a.
Function
17
Because the parties do not dispute the functionality of this claim, the Court adopts
18
the stipulated construction of “providing an indicia of a time of successful transmission
19
of the dispatch to the destination receiving system, said time related indicia being
20
recorded by the authenticator and provided in a manner resistant to or indicative of
21
tampering by either of the sender and the recipient.”
22
23
24
25
26
27
28
b.
Corresponding Structure
The Court has identified the following passages from the specification as
disclosing corresponding structure for the claimed function:
The authenticator 70 also comprises . . . an internal clock 50 for
generating a time indication 66 . . . .
‘219 Patent col. 6 ll. 66–col. 7 ll. 3 (emphasis added).
The internal clock 50 provides an indication 66 of the current time,
and is utilized to provide a time indication for the transmission. Internal
- 123 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
clock 50 is securable (to ensure the veracity of the produced time indication
66), and preferably provides time indications according to a non-changing
time standard, such as Greenwich–Mean–Time (G.M.T.) or UTC.
Alternatively, the time indication 66 can be externally obtained, for
example from a communication network server, as long as the source is
secured from being set or modified by an interested party such as the
sender. The security of the time indication can be provided in a number of
ways, such as by factory pre-setting the clock 50 and disabling or password
securing the Set Date/Time function of the internal clock 50. Alternatively,
the clock 50 can maintain a “true offset” with the true preset date/time, that
reflects the offset of the user set date/time from the genuine preset one.
Id. col. 7 ll. 12–28 (emphasis added).
Reference is now made to FIG. 4 which is a block diagram that
illustrates an authenticator 100, constructed and operative in accordance
with a preferred embodiment of the present invention. The authenticator
100 comprises a secure time generator 104, a storage device 106 and a
function executor 102 which has means for inputting the following
information elements: the transmitted information, the destination address,
a time indication generated by the secure time generator 104, and a
dispatch completion indication. Optionally, additional information elements
can be provided as well.
Id. col. 13 ll. 8–18 (emphasis added).
A related embodiment can utilize a Time Stamping Service (TSS)
such as the Digital Notary System (DNS) provided by Surety Technologies
Inc. [1.10], which has been proposed by Haber et al. in their U.S. patent
documents [2]. The certificate 740 or any portion thereof (such as the
signature 742) can be sent to the DNS to be time stamped. Alternatively, an
embodiment of the present invention could internally implement the DNS
scheme. The DNS generates a certificate authenticating the certificate 740.
Utilizing such time stamping schemes is of great advantage, since the DNS
generated certificates are virtually unforgeable, and there is no need to
deposit copies of the certificates with trustees. Since in this case the DNS
time stamps the certificate 740 anyway, the service 750 itself optionally
need not add the time indication 720.
Id. col. 16 ll. 60–col. 17 ll. 7 (brackets in original; italics added for emphasis).
26
As found by Judge Gilstrap, the specification discloses the following
27
corresponding structures: internal clock 50, a communication network server, secure time
28
- 124 -
1
generator 104, and a Time Stamping Service such as the Digital Notary System.
2
GoDaddy does not dispute that an internal clock and a time stamping device should be
3
incorporated in the corresponding structure, and states that it “agrees with RPost’s
4
construction with one exception: the time generator must be secured from being set or
5
modified by an interested party such as the sender.” (Doc. 117 at 20). GoDaddy’s
6
proposed construction, however, appears to exclude both “communications network
7
server” and “secure time generator 104.” See (id.) Based on the express language of the
8
specifications, these two methods of producing an “indicia” of time are preferred
9
embodiments, and the Court agrees with Judge Gilstrap that all of “[t]hese structures
10
should be included in the Court’s construction as alternatives.” RMail, 2013 WL 968246,
11
at *30 (citing Ishida Co., Ltd. v. Taylor, 221 F.3d 1310, 1316 (Fed. Cir. 2000)).
12
On the other hand, the Court concludes that RPost’s proposed construction is
13
deficient in four areas. First, the specification expressly discloses that clock 50 “is
14
securable (to ensure the veracity of the produced time indication 66).” ‘219 Patent col. 7
15
ll. 14 (emphasis added). The specification also discloses how clock 50 is securable:
16
The security of the time indication can be provided in a number of ways,
such as by factory pre-setting the clock 50 and disabling or password
securing the Set Date/Time function of the internal clock 50. Alternatively,
the clock 50 can maintain a “true offset” with the true preset date/time, that
reflects the offset of the user set date/time from the genuine preset one.
17
18
19
20
21
22
23
24
25
26
27
28
Id. col. 7 ll. 21–28. Implicit in RPost’s argument that “communications network server”
is the only structure with a “secured” limitation is that the express “securable” limitation
does not apply to clock 50. See (Doc. 114 at 18). While the inventor did not use the term
“secured” to limit clock 50—which he readily could have done—the specification does
disclose that clock 50 is at least “securable.” By doing so, the inventor chose to limit the
nature of clock 50 as able to be secured. Accordingly, the Court’s construction includes
“securable” as a limitation for clock 50.
Second, as expressly set forth in the specification, “communications network
server” is limited as “secured from being set or modified by an interested party such as
- 125 -
1
the sender.” ‘219 Patent col. 7 ll. 18–21. RPost does not dispute this limitation applies
2
and notes that it is “amenable to a construction that adds this limitation to the
3
communication network server.” (Doc. 119 at 12–13). Accordingly, the Court
4
incorporates this limitation in its construction.
5
Third, the Court finds that the jury would be better served by defining the four
6
corresponding structures by their location in relation to the authenticator, i.e., internal or
7
external. As GoDaddy argues here and as RPost argued before Judge Gilstrap, the
8
location of the time generator with respect to the authenticator is determinative of
9
whether the generator must be “secured from being set by an interested party such as the
10
sender.”25 Based on the specification language and the preferred embodiments, the Court
11
finds that two corresponding structures are internal to the authenticator and two are
12
external. Specifically, clock 50 and time generator 104 are internal to the authenticator,
13
see ‘219 Patent col. 6 ll. 66–col. 7 ll. 3, Fig. 2, col. 13 ll. 11–12, Fig. 4, while the Time
14
Stamping Service and communication network server are both external to the
15
authenticator, see id. col. 7 ll. 17–21, col. 16 ll. 60–col. 17 ll. 7. As a result, the
16
specification mandates that the Time Stamping Service and communication network
17
server be “secured from being set or modified by an interested party such as the sender”
18
as they are both “external” structures. Id. col. 7 ll. 18–21.
19
Finally, the specification discloses that time generator 104 is “secure.” The Court
20
finds that the jury would be aided by a construction that defines “secure.” The
21
specification defines a “secure” external time generating structure as one that is “secured
22
23
24
25
26
27
28
25
In the case before Judge Gilstrap, RPost proposed a similar corresponding
structure as the one now adopted by the Court. Specifically, RPost proposed “the
corresponding structures disclosed in the specification are an internal clock 50 located
within the authenticator or an externally obtained time source that is secured from being
set by an interested party such as the sender.” RMail, 2013 WL 968246, at *27 (emphasis
added). Thus, RPost recognizes that if the time source is obtained from an external
structure, the specification requires that the external structure must be secured from being
set by an interested party. Although RPost did not propose a similar construction here, the
Court incorporates this express limitation in its construction.
- 126 -
1
from being set or modified by an interested party such as the sender.” Id. Because the
2
specification discloses that time generator 104 is “secure,” the Court finds that the
3
“secure” limitation applicable to “external” structures equally applies to time generator
4
104.
5
For these reasons, the Court concludes that the corresponding structure for “means
6
for providing an indicia of a time of successful transmission” is “either a (1) securable
7
clock 50 and equivalents thereof; (2) time generator 104 and equivalents thereof;
8
(3) communications network server and equivalents thereof; or (4) Time Stamping
9
Service, such as the Digital Notary System, and equivalents thereof; where structures
10
(1) and (2) are internal to the authenticator, structures (3) and (4) are external to the
11
authenticator, and structures (2), (3) and (4) are secured from being set or modified by an
12
interested party such as the sender.”
14
“means for securing at least part of the authentication data against
tampering of the sender and the recipient; wherein the processor is
combined with the means for securing” (Term No. 9)
15
1.
13
H.
The Parties’ Positions
16
Like Term No. 8, the parties agree that this claim is subject to MPF construction,
17
stipulate as to the claim’s functionality, but dispute the corresponding structure. As to
18
structure, RPost contends that the Court should adopt Judge Gilstrap’s construction of
19
“storage unit 54 or storage device 106, and their equivalents.” (Doc. 114 at 18–19).
20
GoDaddy responds that the corresponding structure should be “using a
21
compression, private or public key encryption or scrambling technique, a password, or a
22
combination thereof, such as those employed by the widely used RSA encryption
23
method, and by the PKZIIP(tm) program from PKWARE Inc., Glendale, Wis., U.S.A.,
24
and where the ‘securing’ procedure, key or password are unknown to any interested
25
party.” (Doc. 117 at 20–21). During the Markman Hearing, GoDaddy argued that RPost’s
26
proposal should be rejected because “storage unit 54” and “storage device 106” are nonce
27
terms that disclose no structure. GoDaddy also asserted that an algorithm is necessary for
28
- 127 -
1
a processor to perform the claimed function and that its proposed structure is the only
2
algorithm disclosed in the specification.
3
RPost replies that GoDaddy’s proposed structure is merely an alternative to
4
storage unit 54 in the claim specification and not the only structure providing a means for
5
securing the information. (Doc. 119 at 13). By excluding storage unit 54 and storage
6
device 106 from the corresponding structure, RPost contends that GoDaddy’s proposal
7
should be rejected for conflicting with the intrinsic record. (Id.)
8
9
10
11
2.
Legal Standard
Because this claim is subject to § 112(6), the Court will apply the two step
approach for MPF claim construction as set forth in Term No. 7.
3.
Analysis
12
This disputed phrase is found in Claim 82 as follows:
13
82. An information dispatch system in an electronic communication
network comprising;
14
15
16
17
18
19
20
21
22
23
24
...
an authenticator functioning as a non-interested third party with
respect to the sender and the recipient for authenticating the dispatch and
contents of the dispatch transmitted from the source transmitting system to
the destination receiving system, including;
...
(3) a processor for associating the content data with dispatch record
data which includes at least said time related indicia and an indicia relating
to the destination of the dispatch, to generate authentication data which
authenticate[s] the dispatch and the contents of the dispatch.
(4) means for securing at least part of the authentication data
against tampering of the sender and the recipient;
wherein the processor is combined with the means for securing.
25
26
27
28
- 128 -
1
2
‘219 Patent col. 4 ll. 4–41 (amended version) (emphasis added)
a.
Function
3
Because the parties do not dispute the functionality of this claim, the Court adopts
4
the stipulated construction of “securing at least part of the authentication data against
5
tampering by either the sender or the recipient.”
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
b.
Corresponding Structure
The parties have identified the following passages from the specification as
disclosing corresponding structure:
The authenticator 70 also comprises an optional storage unit 54 such
as a tape, disk or memory device and so forth for storing the information 60
and related dispatch information . . . .
‘219 Patent col. 6 ll. 66–col. 7 ll. 2 (emphasis added).
The storage unit 54 is used for storing the information 60 and/or the
dispatch information, including the address 62, the time indication 66, and
optionally the transmission completion indication 64. Typically, the storage
unit 54 is relatively secure, such that the authentication-information
contained therein is assumed unchangeable. For example it may be a
Write–Once–Read–Many (WORM) device such as an optical disk or a
Programmable Read–Only Memory (PROM) device, it may be enclosed
within a securable device, or it may be provided with read-only access
privilege. Alternatively, the authentication-information is stored in a secure
manner, for example using a compression, private or public key encryption
or scrambling technique, a password, or a combination thereof, such as
those employed by the widely used RSA encryption method, and by the
PKZIP(tm) program from PKWARE Inc., Glendale Wis., U.S.A., and
where the “securing” procedure, key or password are unknown to any
interested party.
The controller 56 associates the information 60 and the dispatch
information, by storing them in storage unit 54 and by associating link
information with the stored authentication-information . . . .
To provide the authentication-information for the transmission, the
dispatch identifier is provided to the controller 56 through the user interface
48. The controller 56, in turn, retrieves the various stored authenticationinformation elements from storage unit 54. If the stored information is also
secured (i.e., by compression, password, etc.), the controller 56 “unsecures”
them, and then provides them to the output unit 58.
- 129 -
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Id. col. 7 ll. 41–col. 8 ll. 5 (emphasis added).
Similarly, information transmitted in a computer network or
electronic mail system can be authenticated, for example, by having a file
server or mail manager (whose time generator is considered secure) store
the transmitted information together with its associated dispatch
information in a secure manner. One embodiment of secure storage is that
which has read-only privileges. Alternatively, such read-only effect can
also be obtained by having the authentication-information encrypted with
the authenticator’s private key: everybody can decrypt it using the
authenticator’s public key, but no interested party can change it without
such action being detectable.
Id. col. 9 ll. 56–67 (emphasis added).
Reference is now made to FIG. 4 which is a block diagram that
illustrates an authenticator 100, constructed and operative in accordance
with a preferred embodiment of the present invention. The authenticator
100 comprises a secure time generator 104, a storage device 106, and a
function executor 102 . . . .
....
. . . . Also, preferably the storage device 106 is a WORM device, such as a
PROM. Preferably, a different function is used for each device employing
the function F. This can be achieved for example by using different keys or
codes with each function.
Id. col. 13 ll. 8–41 (emphasis added).
18
Judge Gilstrap construed the corresponding structure of the claimed function as
19
“storage unit 54 or storage device 106, and equivalents thereof.” RMail, 2013 WL
20
968246, at *35. During the Markman Hearing, GoDaddy argued that the specification is
21
required to disclose an algorithm because the claimed function of “securing” cannot be
22
performed by a general purpose computer, but requires a special purpose computer.
23
Although Judge Gilstrap did not analyze whether the Feldbau Patent needed to disclose
24
an algorithm to perform the claimed function, the Court finds that such an analysis is
25
necessary because the claims asserted against GoDaddy involve computer-implemented
26
functions. See Aristocrat, 521 F.3d at 1333.
27
28
- 130 -
i.
1
Applicability of Aristocrat
2
In this case, there is no dispute that the claimed function of “securing” is disclosed
3
as part of a computer-implemented invention. The question before the Court, therefore, is
4
whether “securing” can be performed by a general purpose computer.
5
As set forth in the Court’s analysis for Term No. 7, Aristocrat requires that for
6
computer or processor-implemented claim terms interpreted under § 112(6), the
7
corresponding structure must disclose the algorithm needed to transform the general
8
purpose computer or processor into the special purpose computer. 521 F.3d at 1333. The
9
Aristocrat requirement is limited, however, to cases where an inventor has claimed “a
10
specific function performed by a special purpose computer.” Katz, 639 F.3d at 1316.
11
Where the inventor has merely recited general computer functions such as “processing,”
12
“receiving,” or “storing,” he need not “disclose more structure than the general purpose
13
processor that performs those functions.” Id.
14
As employed by the Feldbau Patent, RPost’s proposed corresponding structures of
15
“storage device 54” and “storage unit 106” do not—despite their labels—merely perform
16
the general computer function of “storing.” Rather, the claim language requires that the
17
devices “secure” data from tampering by interested parties. See ‘219 Patent col. 4 ll. 37–
18
38.26 The Court must therefore determine whether “securing” data is a “general computer
19
function” or a “specific function performed by a special purpose computer.”
20
The Federal Circuit recently provided guidance on this particular issue. In Spa
21
Syspatronic AG v. United States, the disputed claim involved a means for producing a
22
secret microcode or access code for communications between a control unit and specific
23
data. 117 Fed. Cl. 375, 390 (2014). The functionality of the claim was to “secur[e] the
24
data from unauthorized access.” Id. at 390–92. The patent holder argued that separate
25
algorithms were not required for the code limitations due to the Katz exception for
26
27
28
26
Although the specification states that “storage unit 54 is used for storing the
information . . . .” the parties stipulate that the functionality of Claim 82 is “securing” of
information—not merely “storing.”
- 131 -
1
“processing, receiving, and storing” data that general purpose computers could inherently
2
perform. Id. at 391. The Federal Circuit rejected the patent holder’s argument, explaining:
3
The function of producing an access code by one chip and then the
utilization of it by another chip to grant access to its stored data goes
beyond storing or retrieving data. It is the securing of data from
unauthorized access that is claimed in this case. The patentee clearly
intends for the chips to be used in a specific way for a special function,
unlike in Katz.
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Likewise, the production and use of a secret microcode to limit
access or for decryption goes beyond a general purpose function of a
processor. The use of the term “secret” is enough to distinguish from the
generic use of a processor. The secret microcode limitation requires an
algorithm for achieving that function. . . .
Id. at 392 (emphasis added).
In this case, the “securing” functionality of Claim 82 is nearly identical to the
functionality of the disputed claim in Spa Syspatronic. Specifically, like in Spa
Syspatronic, Claim 82 asserts a method of “securing” certain data from unauthorized
access or tampering by interested parties. See ‘219 Patent col. 4 ll. 37–38 (amended
version). For this reason, the Court finds that Claim 82’s “securing” function cannot be
implemented by a general purpose computer but instead must be implemented in a
special purpose computer.
Because a special purpose computer is necessary to perform the functionality of
Claim 82, Aristocrat applies and the Feldbau Patent must disclose an algorithm that
performs the particular function of securing at least part of the authentication data against
tampering by interested parties. See Aristocrat, 521 F.3d at 1333; Net MoneyIN, Inc. v.
VeriSign, Inc., 545 F.3d 1359, 1367 (Fed. Cir. 2008).
ii.
Adequacy of Disclosed Algorithms
GoDaddy asserts that the specification discloses only one algorithm and endorses
that algorithm as the corresponding structure. (Doc. 117 at 20–21). In its briefing, rather
than discussing whether an algorithm is required, RPost merely advocates that the Court
should adopt Judge Gilstrap’s construction. See (Docs. 114 at 18–19; 119 at 18). During
- 132 -
1
the Markman Hearing, RPost stated that it offered GoDaddy’s current proposal as an
2
alternative method before Judge Gilstrap, but did not in this case because Judge Gilstrap
3
rejected the method as too detailed. See RMail, 2013 WL 968246, at *31–35.
4
Initially, the Court finds that RPost’s current proposal is flatly deficient. The
5
Federal Circuit has long held that “[s]imply disclosing a black box that performs the
6
recited function is not a sufficient explanation of the algorithm required to render the
7
[MPF] term definite.” Augme Techs., Inc. v. Yahoo! Inc., 755 F.3d 1326, 1337–38 (Fed.
8
Cir. 2014) (citing ePlus, Inc. v. Lawson Software, Inc., 700 F.3d 509, 518 (Fed. Cir.
9
2012)). Both “storage unit 54” and “storage device 106” are merely “black box” terms
10
found in Figures 2, 3, and 4 of the specification and do not provide an algorithm as
11
required by Aristocrat. Therefore, the Court rejects RPost’s proposed construction.
12
Beyond “storage unit 54” and “storage device 106,” the specification discloses
13
several methods of “securing” authentication-information. Namely, the specification
14
provides three separate and “relatively secure” methods of storing authentication-
15
information via storage unit 54 and a fourth “secure” method as an alternative. The
16
“relatively secure” methods disclose storage unit 54 as being (1) a “Write-Once-Read-
17
Many (WORM) device such as an optical disk or a Programmable Read-Only Memory
18
(PROM) device”; (2) “enclosed within a securable device”; or (3) “provided with read-
19
only access privilege.” ‘219 Patent col. 7 ll. 46–51. The alternative “secure” method
20
requires “using a compression, private or public key encryption or scrambling technique,
21
a password, or a combination thereof such as those employed by the widely used RSA
22
encryption method, and by the PKZIP(tm) program from PKWARE Inc., Glendale Wis.,
23
U.S.A., and where the “securing” procedure, key or password are unknown to any
24
interested party.” Id. col. 7 ll. 51–58. The question before the Court is which, if any, of
25
these methods set forth a sufficient algorithm that satisfies Aristocrat.
26
The first method discloses storage unit 54 as a “Write-Once-Read-Many (WORM)
27
device such as an optical disk or a Programmable Read-Only Memory (PROM) device.”
28
Id. col. 7 ll. 46–48. As to the securing process, the specification explains that controller
- 133 -
1
56 “stores” and “retrieves” the information from storage unit 54, and “unsecures” the
2
information if it is “secured.” Id. col. 7 ll. 59–col. 8 ll. 5. Under Federal Circuit law, “[i]t
3
is well settled that simply disclosing software . . . without providing some detail about the
4
means to accomplish the function, is not enough.” Function Media, 708 F.3d at 1318
5
(citation and quotations omitted). This first method of “securing,” however, does not
6
simply disclose the generic term “software,” but provides particular types of software that
7
inherently assure that the data written on the device cannot be tampered with once it is
8
written on the device. See Dictionary of Computer Science Engineering and Technology
9
534 (Philip A. Laplante ed., 2000) (defining “write once read many” as “used to refer to
10
memory devices that allow data to be written once after device fabrication, and to be read
11
any number of times. A typical example is PROM.”); Dictionary of Information
12
Technology 505 (Ramesh Bangia ed., 2d 2010) (defining WORM as “Storage device that
13
uses an optical medium that can be recorded only once. Updating requires destroying the
14
existing data . . . .”).
15
The Court finds that the disclosed step of storing the authentication data on a
16
WORM device properly limits the scope of the “corresponding structure, material, or
17
acts” that perform the function of “securing,” as required by § 112(6). Due to the innate
18
“secured” characteristic of a WORM device, the single step of storing the data on such a
19
device is all that is required to perform the claimed function of “securing at least part of
20
the authentication data against tampering by either the sender or the recipient.” See Noah,
21
675 F.3d at 1313 (finding that a specification set forth a sufficient algorithm by
22
disclosing “that authorized agents are provided with passcodes and that agents cannot
23
enter, delete, review, adjust or process data inputs within the master ledger unless the
24
passcode is verified”). Consequently, the Court concludes that this method of “securing”
25
data from tampering by an interested party adequately sets forth an algorithm and
26
therefore constitutes corresponding structure. See Ericsson, 417 F.3d at 1249 (Fed Cir.
27
28
- 134 -
1
2005) (“[T]he corresponding structure for a § 112 ¶ 6 claim for a computer-implemented
2
function is the algorithm disclosed in the specification.”).27
3
As to the second method, the Federal Circuit holds that a purported algorithm
4
cannot “merely provide[] functional language.” Ergo Licensing, 673 F.3d at 1365.
5
Moreover, simply reciting the claimed function in the specification, while including
6
nothing about how the computer or processor ensures that those functions are performed,
7
is not a sufficient disclosure for an algorithm. See Blackboard, Inc. v. Desire2Learn, Inc.,
8
574 F.3d 1371, 1384 (Fed. Cir. 2009). Here, the specification simply discloses that
9
storage device 54 is “enclosed within a securable device.” ‘219 Patent col. Such nonce
10
terminology merely discloses functional language without any form of structure. See
11
Williamson, 792 F.3d at 1350 (citing MIT, 462 F.3d at 1354); Robert Bosch, LLC v.
12
Snap-On, Inc., 769 F.3d 1094 (Fed. Cir. 2014) (finding that the word “device” is
13
generally a non-structural, nonce term (citing cases)). For this reason, the Court finds that
14
a sufficient algorithm has not been disclosed for this method.
15
The third disclosed method to “secure” the authentication data via storage unit 54
16
is “it may be provided with read-only access privilege.” ‘219 Patent col. 7 ll. 50–51. The
17
specification devotes only one other sentence to this method: “[o]ne embodiment of
18
secure storage is that which has read-only privileges.” Id. col. 9 ll. 56–67. Unlike the first
19
disclosed method of storing the data on a WORM or PROM device, the sole step of
20
“[p]rovid[ing the data] with read-only privilege” does not set forth a step-by-step
21
procedure for how the claim’s function of “securing” is to be performed. See Triton Tech
22
of Texas, LLC v. Nintendo of Am., Inc., 753 F.3d 1375, 1378–79 (Fed. Cir. 2014)
23
(“However, merely using the term ‘numerical integration’ does not disclose an
24
25
26
27
28
27
The Court notes that storage device 106 also sets forth storing the data on “a
WORM device, such as a PROM.” ‘219 Patent col. 13 ll. 36–37. As the Court determined
for storage unit 54, this sets forth sufficient structure. Further, because the algorithm is
the corresponding structure, the WORM device is the structure, not simply storage device
106. See Ericsson, 417 F.3d at 1249.
- 135 -
1
algorithm—i.e., a step-by-step procedure—for performing the claimed function [of
2
integrator means].” (citing Ergo Licensing, 673 F.3d at 1365)). For example, the
3
specification does not explain how the data is “provided” with read-only access or who
4
has access to the data. For these reasons, the Court finds that this method fails to disclose
5
a sufficient algorithm.
6
The fourth method of “securing” authentication data is “using a compression,
7
private or public key encryption or scrambling technique, a password, or a combination
8
thereof, such as those employed by the widely used RSA encryption method, and by the
9
PKZIIP(tm) program from PKWARE Inc., Glendale, Wis., U.S.A., and where the
10
‘securing’ procedure, key or password are unknown to any interested party.” The Court
11
finds that this method sufficiently describes an algorithm to accomplish the claimed
12
function of securing data against unauthorized access. See Noah, 675 F.3d at 1313.
13
Accordingly, the Court finds that the corresponding structure for “means for
14
securing at least part of the authentication data against tampering of the sender and the
15
recipient wherein the processor is combined with the means for securing” is “securing the
16
authentication data either (1) by storing the data on a write-once read-many (“WORM”)
17
device such as an optical disk or a Programmable Read-Only Memory (“PROM”) device;
18
or (2) by storing the data using a compression, private or public key encryption or
19
scrambling technique, a password, or a combination thereof, such as those employed by
20
the widely used RSA encryption method, and by the PKZIIP(tm) program from
21
PKWARE Inc., Glendale, Wis., U.S.A., and where the ‘securing’ procedure, key or
22
password are unknown to any interested party.” See Ericsson, 417 F.3d at 1249.
23
24
25
26
27
28
I.
“source transmitting system” (Term No. 10) / “destination
receiving system” (Term No. 11)
1.
The Parties’ Positions
The primary difference between the parties’ proposed constructions for these
disputed claim terms involves the word “system.” RPost proposes that “source
transmitting system” be construed as “system for transmitting a dispatch for a sender”
- 136 -
1
and “destination receiving system” as “system for receiving a dispatch for a recipient.”
2
(Doc. 114 at 19). RPost insists that its constructions are “consistent with the plain claim
3
language.” (Id.)
4
Parroting its proposed constructions for “sender” (Term No. 5) and “recipient”
5
(Term No. 6), GoDaddy proposes that “source transmitting system” be construed as “the
6
computer that originates the dispatch” and that “destination receiving system” be defined
7
as “the computer that receives the dispatch at its intended destination.” (Doc. 117 at 21).
8
GoDaddy explains that its proposed constructions are necessary to clarify that the two
9
systems are computer-based. (Id.) GoDaddy cautions that if the Court were to adopt
10
RPost’s “ambiguous” constructions, the jury could misinterpret “system” to mean any
11
“system” regardless of whether it is computer-based. (Id.) Further, during the Markman
12
Hearing, GoDaddy argued that “system” is a nonce word that discloses no structure.
13
RPost replies that GoDaddy’s ambiguity argument is “unfounded” because
14
GoDaddy stipulated to a construction of “sub-system” for another term. (Doc. 119 at 13);
15
see infra at 26. RPost also stresses that the “computer-based” limitation is already
16
disclosed in the claim, making a recitation of “computer” in either construction
17
unnecessary. (Doc. 119 at 13).
18
2.
Analysis
19
These two terms are disclosed in Claim 82 as follows:
20
82. An information dispatch system in an electronic communication
network comprising;
21
22
23
24
25
26
27
28
a source transmitting system coupled to the electronic
communicating network for sending a dispatch from a sender to a recipient;
a destination receiving system coupled to the electronic
communication network for receiving the dispatch for the recipient
‘219 Patent col. 4 ll. 4–9 (amended version) (emphasis added).
The Court finds little merit in GoDaddy’s fear that the jury could misinterpret
“system” to be something other than a “computer-based” system. Claim 82’s preamble
expressly states that both “source transmitting system” and “destination receiving
- 137 -
1
system” must be “in an electronic communication network.” Id. col. 4 ll. 4–5 (emphasis
2
added). Moreover, Claim 82 requires that each “system” be “coupled to the electronic
3
communication network.” Id. col. 4 ll. 6; id. col. 4 ll. 9. As a result, neither “system”
4
could be interpreted as anything other than a computer-based system. Moreover, while
5
the Court agreed with GoDaddy that the terms “recipient” and “sender” have “plain and
6
ordinary meanings” that include natural persons, the same does not hold true for “source
7
transmitting system” or “destination receiving system”—particularly when both systems
8
are “in an electronic communication network.” The Court nevertheless concludes that the
9
jury would be aided by a construction that limits “system” as being “computerized.”
10
Furthermore, the Court finds that limiting the term “system” to “computer” as
11
GoDaddy proposes would be improper. GoDaddy has not persuaded the Court that Claim
12
82 only embodies “computers” per se. While it is undisputed that each claimed “system”
13
must be “electronic” or “computerized,” construing “system” simply as “computer” could
14
imply to the jury that the “transmitting” and “receiving” systems can only be
15
“computers” and not another type of computerized system.
16
Additionally, the Court is not convinced that GoDaddy’s proposed language of
17
“originates” is accurate. Specifically, the claim does not disclose that the “source
18
transmitting system” originates the message. In fact, the parties stipulated that the
19
“sender originates” the entire content of the message. (Doc. 191-1 at 14) (emphasis
20
added). GoDaddy has not shown that “sender” and “source transmitting system” are
21
synonymous such that the doctrine of claim differentiation is overcome. See Andersen
22
Corp. v. Fiber Composites, LLC, 474 F.3d 1361, 1369 (Fed. Cir. 2007) (explaining that
23
the doctrine of claim differentiation is based on “the common sense notion that different
24
words or phrases used in separate claims are presumed to indicate that the claims have
25
different meanings and scope.” (quoting Karlin Tech. Inc. v. Surgical Dynamics, Inc.,
26
177 F.3d 968, 971–72 (Fed. Cir. 1999))).
27
GoDaddy’s proposed construction for “destination receiving system” also includes
28
the limitation “at its intended destination.” (Doc. 117 at 21). GoDaddy does not discuss
- 138 -
1
this proposed limitation in its briefing but explained at the Markman Hearing that “[t]he
2
whole point of the invention is to confirm or verify that the message was delivered at its
3
intended destination hence that aspect of GoDaddy’s claim construction.” As it found for
4
Term No. 6, the Court concludes that including this limitation requires the jury to engage
5
in unnecessary additional inquiry.
6
For these reasons, the Court construes “source transmitting system” as
7
“computerized system for transmitting a dispatch for a sender” and “destination receiving
8
system” as “computerized system for receiving a dispatch for a recipient.”
9
VIII. Conclusion
10
For the foregoing reasons,
11
IT IS ORDERED that the Court adopts the constructions, pursuant to Markman,
12
as set forth in this Order for the disputed terms of the Tomkow and Feldbau Patents.
13
IT IS FURTHER ORDERED that the parties may not refer, directly or
14
indirectly, to each other’s claim construction positions in the presence of the jury.
15
Likewise, the parties are ordered to refrain from mentioning any portion of this Order,
16
other than the actual definitions adopted by the Court, in the presence of the jury. Any
17
reference to claim construction proceedings is limited to informing the jury of the
18
definitions adopted by the Court.
19
Dated this 19th day of January, 2016.
20
21
22
23
24
25
26
27
28
- 139 -
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?