SYMANTEC CORPORATIONv.RPOST COMMUNICATIONS LIMITED

Patent Trial and Appeal Board

Jul 15, 2014

12794663 (P.T.A.B. Jul. 15, 2014)

Trials@uspto.gov Paper 15
571-272-7822 Entered: July 15, 2014

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

SYMANTEC CORPORATION,
Petitioner,

v.

RPOST COMMUNICATIONS LIMITED,
Patent Owner.

Case IPR2014-00353
Patent 8,504,628

Before THOMAS L. GIANNETTI, BEVERLY M. BUNTING, and
MATTHEW R. CLEMENTS, Administrative Patent Judges.

CLEMENTS, Administrative Patent Judge.

DECISION
Denying Institution of Inter Partes Review
37 C.F.R. § 42.108

IPR2014-00353
Patent 8,504,628

2
I. INTRODUCTION
Symantec Corporation (“Petitioner”) filed a Petition requesting inter
partes review of claims 1-30 (“the challenged claims”) of U.S. Patent No.
8,504,628 (Ex. 1001, “the ’628 patent”). Paper 2 (“Pet.”). RPost
Communications Limited (“Patent Owner”) filed a Preliminary Response.
Paper 12 (“Prelim. Resp.”). We have jurisdiction under 35 U.S.C. § 314.
Upon consideration of the Petition and Preliminary Response, we
determine that the information presented by Petitioner has not established
that there is a reasonable likelihood that Petitioner would prevail in showing
unpatentability of claims 1-30 of the ’628 patent. Accordingly, the Petition
is denied.
A. Related Proceedings
Petitioner indicates that the ’628 patent is involved in four co-pending
district court cases: RPost Holdings, Inc. et al v. Sophos, Inc., 2:13-cv-
00959 (E.D. Tex.); RPost Holdings, Inc. et al v. Trend Micro Incorporated,
2:13-cv-01065 (E.D. Tex.); Sophos Incorporated v. RPost Holdings, Inc. et
al, 1:13-cv-12856 (D. Mass.); and Trend Micro Incorporated v. RPost
Holdings, Inc. et al, Case No. 3:13-cv-05227 (N.D. Cal.). Pet. 1. Patent
Owner indicates that the ’628 patent is related to two additional co-pending
district court cases: RPost Holdings, Inc. et al. v. Symantec Corporation,
2:14-cv-00028 (E.D. Tex.); Symantec Corporation v RPost Holdings, Inc. et
al., 3:14-cv-238 (N.D. Cal.). Paper 9, 2. Patent Owner also identifies two
petitions for inter partes review of other related patents of Patent Owner:
IPR2014-00355 (U.S. Patent No. 7,966,372), IPR2014-00357 (U.S. Patent
No. 8,468,199). Id. Patent Owner also identifies three petitions for covered
business method review of other related patents of Patent Owner:
IPR2014-00353
Patent 8,504,628

3
CBM2014-00010 (U.S. Patent No. 8,224,913), CBM2014-00017 (U.S.
Patent No. 8,209,389), and CBM2014-00064 (U.S. Patent No. 8,161,104).
Id. Patent Owner also identifies ex parte reexamination of U.S. Patent No.
8,275,845 (Control No. 90/012,771). Id.
B. The ’628 patent
The ’628 patent “relates generally to a system and method for
verifying delivery and content of an electronic message.” Ex. 1001, 1:20-21.
In particular, the ’628 patent relates “to a system and method of later
providing proof regarding the delivery and content of an e-mail message.”
Id. at 1:22-24. According to the ’628 patent, there was a need for an email
system that can provide reliable proof of the content and delivery of
electronic messages and which does not require the compliance or
cooperation of the recipient, does not require special software on the part of
the sender or recipient, operates with the same or nearly the same
convenience and speed as conventional email, and which can be operated
economically by a service provider. Id. at 2:62-3:2.
To address this need, the ’628 patent discloses “an electronic message
system that creates and records a digital signature of each electronic message
sent through the system.” Id. at 3:16-18. Figure 1 is reproduced below:
IPR2014-00353
Patent 8,504,628

4

Figure 1 is a system diagram of a first embodiment, wherein outgoing emails
are registered according to the present invention. Id. at 6:35-37. “RPost
registering server 14 serves as the primary outgoing Mail Transport Agent
(MTA) for a message sender’s Mail User Agent (MUA) 13.” Id. at 6:38-40.
The method of sending registered messages involves three parts: (1) pre-
processing; (2) transmission; and (3) post-processing. Id. at 6:47-55.
Pre-processing
During pre-processing of a message, the RPost server creates a record
in a database that includes, e.g., “the time at which the message was
received, the names of the attachments of the message, [and] the number of
addresses of the message.” Id. at 6:56-62. For each destination of a
message, the record also includes the name of the destination, the internet
address of the destination, the time at which the message was delivered to
IPR2014-00353
Patent 8,504,628

5
the destination’s mail server, and the delivery status of the destination (e.g.,
UNSENT, DELIVERED, UNDELIVERABLE). Id. at 6:63-7:33. RPost
server 14 will then configure the message in a way that attempts to elicit
both MTA notifications and MUA notices from compliant MTAs and
MUAs. Id. at 9:4-6.
An MTA notification is an email sent by a recipient’s MTA that
notifies the nominal sender of the message that various events have
occurred. Id. at 8:31-34. MTAs that conform to the SMTP protocol
typically send a notification only if the mailer cannot deliver the message to
the mailbox of the address. Id. at 8:34-39. MTAs that conform to the
ESMTP can send notices of success and failure in the delivery of a message.
Id. at 8:40-42. These Delivery Status Notifications (DSNs) are emails
sent by a receiving MTA to the nominal sender of the message
when certain events occur: e.g. the message has been
successfully deposited into the mailbox of the recipient; the
message cannot be delivered to the recipient’s mailbox for
some reason; the recipient’s message has been relayed on to
another server which does not give DSN receipts.
Id. at 8:42-50. The ’628 patent uses the term “‘DSN’ to refer to any MTA
generated message relating to the status of a received message.” Id. at 8:56-
60.
“In order to elicit a Reading Receipt from compliant MUAs,” RPost
server 14 includes certain headers in the header section of the email
message. Id. at 9:6-8. Because the method of the ’628 patent requires that
the notification be returned to RPost server 14 so that it can be processed,
the server inserts headers that request that MUA receipts be sent to an
address where they can be processed by RPost server 14—e.g.,
“readreceipt@RPost.com.” Id. at 9:23-29.
IPR2014-00353
Patent 8,504,628

6
In order to elicit and collect MTA DSN notices generated by recipient
MTAs, which are usually sent to the address listed in the “FROM:” field of
the message header, RPost server 14 alters each message header so that the
message is received as “FROM:” an RPost address at which DSNs for that
message may be processed. Id. at 10:7-11:3. When the recipient MTA
issues DSNs for a received message, it will address those DSNs to an RPost
address unique to that message. Id. at 11:4-7. On receiving those DSNs,
RPost server 14 can identify them as DSN messages and, by parsing the
addressees, can determine which message and which recipient is the subject
of the DSN. Id. at 11:7-10.
Transmission
Before transmitting a copy of a message to any destination, RPost
server 14 performs an Internet Name Server Lookup to identify an MTA
associated with the destination’s domain. Id. at 11:42-45. If the MTA
responsible for receiving mail on behalf of the destination address is
identified, RPost server 14 attempts to open a telnet connection with the
destination MTA. Id. at 11:45-48. RPost server 14 attempts to open an
ESMTP connection with the destination MTA 16 and, if successful, will
transmit the message with a request that destination server 16 notify the
sender of the message with an ESMTP DSN if the delivery to the addressee
succeeds or fails. Id. at 12:24-27. If destination MTA 16 does not support
ESMTP, RPost server 14 initiates an SMTP connection and, if successful,
transmits the message in compliance with the SMTP protocol. Id. at
12:58-64.
Whether the connection is SMTP or ESMTP, RPost server 14 will
record the entire protocol dialogue between the two servers. Id. at 12:65-67.
IPR2014-00353
Patent 8,504,628

7
By connecting directly between RPost server 14 and the destination MTA,
the RPost server can record delivery of the message in the form of the SMTP
dialogue with the MTA that is responsible for receiving email for the
recipient domain name. Id. at 11:50-56. Every successful delivery directly
to a recipient MTA will always generate an SMTP record that allows RPost
to provide proof of delivery to any valid Internet destination that complies
with the minimum protocols (SMTP) for Internet email. Id. at 12:15-20.
According to the ’628 patent, this is an important advantage over other
methods that rely only on ESMTP DSNs to prove delivery. Id. at 12:20-23.
Post-processing
MTA DSNs will be returned to the RPost addresses constructed as
described above. Id. at 13:30-33. By parsing these addresses, the system
can identify the message and the recipient that prompted the DSN
notification. Id. at 13:36-38. After evaluating a DSN and updating the
recipient’s delivery status accordingly, the system will save the DSN and
any attachments in a way that it may be included in or attached to an RPost
Delivery Receipt. Id. at 13:63-67. “When the system finds that delivery to
all recipients of a message has been completed, the system will construct a
Delivery Receipt for the message.” Id. at 14:53-55. “Delivery receipts are
e-mails sent to the original sender of the Registered message.” Id. at
14:57-58.
MUAs that are returned to the common RPost address (e.g.,
“‘readreceipts@RPost.com’”) are passed on to the sender for his own
evaluation in a form that can be authenticated by RPost. Id. at 15:60-16:30.
In the event that the originator of a message later requires evidence
that an email was sent, delivered, or read, the originator presents the
IPR2014-00353
Patent 8,504,628

8
receipt(s) for the message to the operators of the RPost system. Id. at
17:5-8. “RPost can then provide authentication, verification, and
confirmation of the information contained within the receipt.” Id. at
17:44-46.
C. Illustrative Claim
Of the challenged claims, claims 1, 14, and 30 are independent.
Claim 1 is reproduced below:
1. A method of transmitting a message from a sender to a
recipient, comprising:
adding a particular indication to a message to be sent to a
recipient, the particular indication identifying the message as
requiring special processing;
transmitting the message to a server remote from the
recipient;
determining at the server whether the message has the
particular indication before the message is transmitted from the
server to the recipient;
transmitting the message from the server to the recipient
through a first route if the message lacks the particular
indication; and
processing the message by the server in accordance with
the particular indication.
D. References Relied Upon
Petitioner relies upon the following references and the Declaration of
Paul Clark, DSc. (Ex. 1004):
Al-Hammadi, Bassam, and Mohammad Mehdi Shahsavari.
“Certified exchange of electronic mail (CEEM),” Southeastcon
'99, Proceedings, IEEE, pp. 40-43, IEEE, 1999. (“CEEM”)
Ex. 1009
IPR2014-00353
Patent 8,504,628

9
Bahreman, Alireza, and J. D. Tygar, Certified electronic mail,
MS thesis, Carnegie Mellon University, 1992. (“CEM”)
Ex. 1010
Allman, Eric, SENDMAIL
TM
INSTALLATION AND OPERATION
GUIDE, Version 8.127 (“S89”)
Ex. 1013
Kent, Stephen T., Internet Privacy Enhanced Mail, 36
COMMUNICATIONS OF THE ACM 48-60 (1993) (“Kent”)
Ex. 1014
E. The Asserted Grounds of Unpatentability
Petitioner argues that the challenged claims are unpatentable based
upon the following grounds:
Reference(s) Basis Claims challenged
S89 § 102 1-30
CEM § 102 1-30
S89, CEEM, and Kent § 103 1-30
II. ANALYSIS
A. Claim Construction
In an inter partes review, claim terms in an unexpired patent are
interpreted according to their broadest reasonable construction in light of the
specification of the patent in which they appear. 37 C.F.R. § 42.100(b);
Office Patent Trial Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14,
2012). Also, claim terms are given their ordinary and customary meaning,
as would be understood by one of ordinary skill in the art in the context of
the entire disclosure. In re Translogic Tech., Inc., 504 F.3d 1249, 1257
(Fed. Cir. 2007).
For purposes of this decision, we construe the following claim term
and need not construe expressly any of the other claim terms at this time.
IPR2014-00353
Patent 8,504,628

10
“particular indication identifying the message as requiring special
processing” (claim 1) / “particular indication present in the message
that identifies the message as requiring special processing” (claim
14) / “particular indication present in the message that identifies the
message as requiring special processing” (claim 30)
Petitioner proposes that “particular indication” be construed to be
“either based on the content of the message itself, sender/recipient
information, flags, or other criteria.” Pet. 7-8. As support for its proposed
construction, Petitioner cites to Patent Owner’s infringement allegations
(Pet. 7 (citing Ex. 1008, 9)). Petitioner also argues that its proposed
construction is supported by claim 10. Pet. 7-8. Patent Owner reserves the
right to contest Petitioner’s proposed construction of this phrase, but does
not propose an alternative construction. Prelim. Resp. 4-5.
The ’628 patent does not define “particular indication” or use that
term apart from within the claims. With respect to where the “particular
indication” must be found, the ’628 patent describes an embodiment in
which a message is “registered” (i.e., identified as requiring special
processing) based upon “some form of flag in an outgoing message, message
subject, or message addresses. Ex. 1001, 22:50-53. For example, if and
only if a sender includes the symbol “(R)” in the subject of the message the
sender’s MTA will direct the message to be transmitted through the RPost
server to generate a receipt.” Id. at 22:50-57. We, therefore, agree with
Petitioner that the “particular indication” may be a flag, the content of the
message, or the sender/recipient information. Moreover, the ’628 patent
does not preclude the “particular indication” from being present in other
portions of the message. The location of the “particular indication” is
limited only by the claims, which require that “the message has the
IPR2014-00353
Patent 8,504,628

11
particular indication” (claim 1) or that “there is a particular indication
present in the message” (claims 14, 30). However, this language is not part
of the claim to be construed. Accordingly, Petitioner’s construction is too
narrow to the extent that it imports limitations on where the “particular
indication” must be found into the construction of the term “particular
indication.”
Conversely, Petitioner’s construction is too broad to the extent that it
encompasses “other criteria” that may or may not identify the message as
requiring special processing.
On this record, and for purposes of this Decision, we construe
“particular indication” to mean “information that identifies a message as
requiring special processing.”
B. Claims 1-30 – Anticipation by S89
Petitioner argues that claims 1-30 are unpatentable under 35 U.S.C.
§ 102(b) as anticipated by S89. Pet. 16-23. In support of this ground of
unpatentability, Petitioner relies upon the Declaration of Paul Clark, DSc.
(“Dr. Clark”). Id. (citing Ex. 1004 ¶¶ 75-87, 91-93, 96, 108, 109).
S89 (Ex. 1013)
S89 is the installation and operation guide for version 8.9 of the
Sendmail™ software. “Sendmail™ implements a general purpose
internetwork mail routing facility under the UNIX® operating system.” Ex.
1013, SMM:08-1. It relays messages from one domain into another and, in
the process, can do a limited amount of message header editing to put the
message into a format that is appropriate for the receiving domain. Id.
Sendmail is based on RFC821 (Simple Mail Transport Protocol), RFC822
(Internet Mail Headers Format), RFC1123 (Internet Host Requirements),
IPR2014-00353
Patent 8,504,628

12
RFC2045 (MIME), RFC1869 (SMTP Service Extensions), RFC1652
(SMTP 8BITMIME Extension), RFC1870 (SMTP SIZE Extension),
RFC1891 (SMTP Delivery Status Notifications), RFC1892
(Multipart/Report), RFC1893 (Mail System Status Codes), RFC1894
(Delivery Status Notifications), RFC1985 (SMTP Service Extension for
Remote Message Queue Starting), and RFC2033 (Local Message
Transmission Protocol). Id.
All messages from Sendmail™ are logged. Id. at SMM:08-13. “Each
line in the system log consists of a timestamp, the name of the machine that
generated it (for logging from several machines over the local area network),
the word “sendmail:”, and a message.” Id. “Most messages are a sequence
of name=value pairs.” Id. “The two most common lines are logged when a
message is processed.” Id. “The first logs the receipt of a message; there
will be exactly one of these per message. Some fields may be omitted if
they do not contain interesting information.” Id. Fields include “from,”
“size,” “class,” “pri,” and others. Id.
System aliases are held in “/etc/aliases.” Id. at SMM:08-11. “After
recipient addresses are read from the SMTP connection or command line
they are parsed by ruleset 0, which must resolve to a {mailer, host, user}
triple.” Id. at SMM:08-16. “If the flags selected by the mailer include the A
(aliasable) flag, the user part of the triple is looked up as the key (i.e., the
left[-]hand side) into the alias database.” Id. “If there is a match, the
address is deleted from the send queue and all addresses on the right hand
side of the alias are added in place of the alias that was found.” Id. “Only
local names may be aliased.” Id.
IPR2014-00353
Patent 8,504,628

13
Analysis
In light of the arguments and evidence, Petitioner has not established a
reasonable likelihood that claims 1-30 are unpatentable as anticipated by
S89.
Independent claim 1 recites, “adding a particular indication to a
message to be sent to a recipient, the particular indication identifying the
message as requiring special processing.” Petitioner relies upon S89’s
disclosure of fields in a log kept by the email server software. Pet. 17 (citing
Ex. 1013, SMM:08-13; Ex. 1004 ¶¶ 77-78). Patent Owner argues that the
fields disclosed in S89 cannot be “add[ed] . . . to a message to be sent to a
recipient” because the logs are created after a message is sent to the server
running the Sendmail software. Prelim. Resp. 9-11 (citing Ex. 1013 at
SMM:08-13). We agree. The fields relied upon by Petitioner are written to
a log file by the Sendmail software. S89 does not disclose that the Sendmail
software adds any of these fields to the message sent from the Sendmail
software.
Independent claim 1 also recites, “transmitting the message from the
server to the recipient through a first route if the message lacks the particular
indication.” Independent claims 14 and 30 recite limitations commensurate
in scope. For this element of independent claims 14 and 30, Petitioner refers
to its analysis of element 1.4, which recites a similar limitation. Pet. 20, 23.
For element 1.4, Petitioner cites S89’s disclosure that the Sendmail software
will not perform aliasing in certain situations such as non-local aliases. Pet.
17-18 (citing Ex. 1013, SMM08:16; Ex. 1004 ¶ 81). The transmitting step,
however, is conditioned upon the message lacking the particular indication
(“if the message lacks the particular indication”). Even if we assume that
IPR2014-00353
Patent 8,504,628

14
Petitioner is relying upon an alias (i.e., the address in the “To:” field) and not
the log fields as the “particular condition,” we are still not persuaded that
S89 discloses this limitation because S89 does not disclose transmitting a
message that lacks an alias—i.e., lacks an address in the “To:” field. To the
extent that Petitioner is relying upon the alias information for the address in
the “To:” field (i.e., the information stored in “/etc/aliases”), we note that
such information cannot be the “particular indication” because that
information is not part of the message, and the “determining” step requires
the “particular indication” to be something that the message “has.”
Conclusion
Based on the record before us, we are not persuaded that Petitioner
has established a reasonable likelihood that it would prevail in showing that
claims 1-30 are unpatentable as anticipated by S89.
C. Claims 1-30 – Anticipation by CEM
Petitioner argues that claims 1-30 are unpatentable under 35 U.S.C.
§ 102(b) as anticipated by CEM. Pet. 23-30. In support of this ground of
unpatentability, Petitioner relies upon the Declaration of Paul Clark, DSc.
(“Dr. Clark”). Id. (citing Ex. 1004 ¶¶ 111, 113-131, 138, 150, 151).
CEM (Exhibit 1010)
CEM describes two families of protocols for certified electronic mail.
Ex. 1010, Abstract. One family of protocols, called the believers’ CEM (“B-
CEM”), uses a trusted third party. Id. at Abstract, 6. Figure 1 is reproduced
below.
IPR2014-00353
Patent 8,504,628

15

Figure 1 depicts the interactions between the parties and the trusted third
party (“Postmaster”) in the B-CEM protocol. Id. at 6. “The postmaster acts
as an independent agent arbitrating the exchange of a receipt from the
recipient (Rob), for the CEM from the sender (Sue).” Id. “In phase one, Sue
prepares the CEM and sends it to the postmaster.” Id. In phase two, the
postmaster sends the proof of mailing to Sue, if required, and encrypts the
CEM to produce ciphertext. Id. “The postmaster then stores a record of the
key, the CEM, sender-recipient information, and any other information to
uniquely identify the transaction.” Id. The postmaster then transmits the
ciphertext to Rob. Id. “In phrase three, Rob signs a receipt corresponding to
the received ciphertext and sends the receipt to the postmaster.” Id. “In
phrase four, the postmaster verifies the receipt and, if valid, stores a copy of
the receipt.” Id. The postmaster then sends the cryptographic key to Rob to
decipher the ciphertext and sends a copy of the receipt and the cryptographic
key to Sue as the return receipt. Id. “In phase five, both parties individually
verify the information they received.” Id.
Analysis
In light of the arguments and evidence, Petitioner has not established a
reasonable likelihood that claims 1-30 are unpatentable as anticipated by
CEM.
Independent claim 1 recites, “transmitting the message from the server
to the recipient through a first route if the message lacks the particular
IPR2014-00353
Patent 8,504,628

16
indication.” Petitioner does not cite CEM; it cites only to Dr. Clark’s
testimony. Pet. 25 (citing Ex. 1004 ¶ 118). Patent Owner argues that CEM
does not disclose this element because Petitioner does not specify where this
element is found in CEM. Prelim. Resp. 25-26. We agree. Paragraph 118
of Dr. Clark’s Declaration references a figure in CEM not cited in the
Petition. Under our rules, the petition must contain a “full statement of the
reasons for the relief requested, including a detailed explanation of the
significance of the evidence.” 37 C.F.R. § 42.22(a)(2). We, therefore,
decline to consider information presented in a supporting declaration, but not
discussed in a petition; among other reasons, doing so would permit the use
of declarations to circumvent the page limits that apply to petitions. For the
same reasons, our rules prohibit arguments made in a supporting document
from being incorporated by reference into a petition. See 37 C.F.R.
§ 42.6(a)(3).
Even if we were to consider the figure of CEM cited by Dr. Clark,
however, we would not be persuaded that CEM discloses this limitation.
We agree with Patent Owner that CEM does not disclose what happens “if
the message lacks the particular indication” (i.e., lacks Sue’s signature).
Prelim. Resp. 26-27. Although Dr. Clark testifies that CEM would transmit
a message through a normal route of email servers and communication links
not passing through the postmaster (Ex. 1004 ¶ 118), that testimony is
conclusory. Accordingly, on this record, we are not persuaded that CEM
discloses this limitation.
Conclusion
Based on the record before us, we are not persuaded that Petitioner
has established a reasonable likelihood that it would prevail in showing that
IPR2014-00353
Patent 8,504,628

17
independent claim 1 is unpatentable as anticipated by CEM. Our
determination concerning the insufficiency of the evidence applies equally to
independent claims 14 and 30, and to dependent claims 2-13 and 15-29.
D. Claims 1-30 – Obviousness over S89, CEEM, and Kent
Petitioner argues that claims 1-30 are unpatentable under 35 U.S.C.
§ 103(a) as obvious over S89, CEEM, and Kent. Pet. 30-42. In support of
this ground of unpatentability, Petitioner relies upon the Declaration of Dr.
Clark. Id. (citing Ex. 1004 ¶¶ 76-85, 87, 91-93, 96, 108, 109, 160-162, 164-
169, 171-187, 193, 194, 201, 213-215).
CEEM (Exhibit 1009)
CEEM describes a “practical certified exchange of electronic mail
protocol that can provide the required proofs for both the originator and
recipient against any repudiation.” Ex. 1009, Abstract. The CEEM protocol
employs a trusted third party to help solve the problem of exchanging the
messages and providing proof of delivery from the recipient. Id. at 15.
“This protocol consists of four main elements: (1) a trusted third party,
represented by the Email Office (EO); (2) the originator; (3) the recipient;
and (4) the communication medium.” Id. “The EO is a third party server
that provides the email handling service in an electronic manner.” Id.
Figure 2 is reproduced below.
IPR2014-00353
Patent 8,504,628

18

Figure 2 shows the integration of the EO into the existing Internet email
architecture. Id. “The EO server implements the Security Policies to
process requests for certified email and uses the Database to save those
messages that are in a waiting state for delivery.” Id. Another part of the
Database is used to keep receipt of delivered email for a length of time
stated in the Security Policies in case of future disputes. Id. “[T]he protocol
has three phases: (1) message preparation; (2) message distribution; and (3)
proofs distribution.” Id.
In the message preparation phase, Alice requests a Certified Email
Form (CEF) from the EO. Id. at 15-16. In the message distribution phase,
Alice encrypts the message, fills, signs, and encrypts the CEF, and sends
both the encrypted message and the encrypted signed CEF to the EO. Id. at
16. The EO decrypts the received message, signs the CEF, encrypts it, and
sends only the encrypted, signed CEF to Bob. Id. Bob decrypts the signed
CEF, reads the CEF, signs the CEF, and sends it back to the EO. Id. If
“Bob accepted the CEF and signed it, the EO will send the signed message
to Bob.” Id.
IPR2014-00353
Patent 8,504,628

19
Kent (Ex. 1014)
Kent describes Requests for Comment (RFCs) 1421 to 1424, which
describe Internet Privacy Enhanced Mail (PEM). Ex. 1014, 1. Kent
describes PEM as “intended for use in conjunction with existing email
systems, primarily Internet email.” Id. at 1-2. Figure 1 is reproduced below.

“Figure 1 illustrates how PEM fits into existing mail system architectures.”
Id. at 2. Messages are prepared on a multiuser computer on which each user
has an individual mailbox and an individual instance of the software
employed for message submission and reception—i.e., User Agent (UA).
Id. This multiuser computer also includes a Message Transfer Agent
(MTA), which is the interface through which all messages exiting this
computer are transmitted and all messages received at this computer are
received. Id.
To maximize compatibility with existing email systems, “PEM is
designed to be transparent to MTAs, so that the existing email transport
infrastructure can be used to transfer PEM messages.” Id. One way of
implementing PEM such that it entails no changes to the UA is to implement
IPR2014-00353
Patent 8,504,628

20
it as a filter applied to a file created using an editor before that file is
provided to the UA. Id. However, this approach can be awkward if, for
example, the user is required to supply recipient identifiers twice—i.e., once
for PEM processing and again for email addressing. Id.
Alternatively, if PEM is integrated into the UA, “a message originator
might identify recipients using either email addresses or local aliases, and
the integrated UA would automatically translate these into the
cryptographically authenticated identifiers used within PEM.” Id.
Both implementations are purely local matters, invisible outside of the
computers on which they appear. Id.
Analysis
In light of the arguments and evidence, Petitioner has not established a
reasonable likelihood that claims 1-30 are unpatentable as obvious over S89,
CEEM, and Kent.
Independent claim 1 recites, “transmitting the message from the server
to the recipient through a first route if the message lacks the particular
indication.” Independent claims 14 and 30 recite limitations commensurate
in scope. For this element of independent claims 14 and 30, Petitioner refers
to its analysis of element 1.4, which recites a similar limitation. Pet. 38,
41-42. For element 1.4, Petitioner cites S89’s disclosure that the Sendmail
software will not perform aliasing in certain situations such as non-local
aliases. Pet. 34 (citing Ex. 1013, SMM08:16; Ex. 1004 ¶ 81). We are not
persuaded that S89 teaches this limitation for the reasons discussed above.
Petitioner also cites Kent’s teaching that PEM is applied selectively
according to a “recipient identifier.” Pet. 34 (citing Ex. 1014, 2; Ex. 1004
¶¶ 171-72). Patent Owner argues that Kent does not teach this limitation.
IPR2014-00353
Patent 8,504,628

21
Prelim. Resp. 41-42. We agree. The transmitting step is conditioned upon
the message lacking the particular indication (“if the message lacks the
particular indication”). Kent does not teach that the route through which a
message is transmitted depends upon whether PEM was applied to the
message. To the contrary, Kent explicitly teaches that transmission does not
depend on whether PEM was applied to the message. Ex. 1014, 2 (“PEM is
designed to be transparent to MTAs;” “Both implementation options [of
PEM] are purely local matters, invisible outside of the computers on which
they appear.”) (Emphasis added). On this record, we are not persuaded that
Kent teaches this limitation.
Conclusion
Based on the record before us, we are not persuaded that Petitioner
has established a reasonable likelihood that it would prevail in showing that
claims 1-30 are unpatentable as obvious over S89, CEEM, and Kent.
III. CONCLUSION
For the foregoing reasons, we determine that the information
presented in the Petition does not establish that there is a reasonable
likelihood that Petitioner would prevail in establishing the unpatentability of
claims 1-30 of the ’628 patent.
Accordingly, we deny the Petition and do not institute an inter partes
review of claims 1-30 of the ’628 patent.
IV. ORDER
Accordingly, it is
ORDERED that the Petition challenging the patentability of claims
1-30 of U.S. Patent No. 8,504,628 is denied and no trial is instituted.
IPR2014-00353
Patent 8,504,628

22
For PETITIONER:

Stuart P. Meyer, Esq.
David D. Schumann
FENWICK & WEST LLP
smeyer-ptab@fenwick.com
Dschumann-ptab@fenwick.com

For PATENT OWNER:

Lewis E. Hudnell, III
HUDNELL LAW GROUP P.C.
lewis@hudnelllaw.com

John K. Fitzgerald
FULWIDER PATTON LLP
docketla@fulpat.com