Paper Entered: July 15, 2014 UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD

Transcription

1 Paper 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 IPR Before THOMAS L. GIANNETTI, BEVERLY M. BUNTING, and MATTHEW R. CLEMENTS, Administrative Patent Judges. CLEMENTS, Administrative Patent Judge. DECISION Institution of Inter Partes Review 37 C.F.R

2 I. INTRODUCTION Symantec Corporation ( Petitioner ) filed a Petition requesting inter partes review of claims 1-20 ( the challenged claims ) of U.S. Patent No. 8,468,199 (Ex. 1001, the 199 patent ). Paper 2 ( Pet. ). RPost Communications Limited ( Patent Owner ) filed a Preliminary Response. Paper 10 ( Prelim. Resp. ). We have jurisdiction under 35 U.S.C The standard for instituting an inter partes review is set forth in 35 U.S.C. 314(a), which provides as follows: THRESHOLD. The Director may not authorize an inter partes review to be instituted unless the Director determines that the information presented in the petition filed under section 311 and any response filed under section 313 shows that there is a reasonable likelihood that the petitioner would prevail with respect to at least 1 of the claims challenged in the petition. Upon consideration of the Petition and Preliminary Response, we determine that the information presented by Petitioner establishes that there is a reasonable likelihood that Petitioner would prevail in showing unpatentability of only claims 9-20 of the 199 patent. Accordingly, pursuant to 35 U.S.C. 314, we institute an inter partes review of claims 9-20 of the 199 patent, and do not institute inter partes review of claims 1-8. A. Related Proceedings Petitioner indicates that the 199 patent is involved in four co-pending district court cases: Trend Micro Incorporated v. RPost Holdings, Inc. et al, Case No. 3:13-cv (N.D. Cal.); Sophos Incorporated v. RPost Holdings, Inc. et al, 1:13-cv (D. Mass.); RPost Holdings, Inc. et al v. Sophos, Inc., 2:13-cv (E.D. Tex.); RPost Holdings, Inc. et al v. Trend Micro Incorporated, 2:13-cv (E.D. Tex.). Pet Patent Owner 2

3 indicates that the 199 patent is related to four additional co-pending district court cases: j2 Global, Inc. et al. v. RPost Holdings, Inc. et al., 2:14-cv (C.D. Cal.); Symantec Corporation v RPost Holdings, Inc. et al., 3:14- cv-238 (N.D. Cal.); GoDaddy.com LLC v. RPost Communications, et al., 2:14-cv-126 (D. Ariz.); and MIS Science Corporation v. RPost Communications, et al., 3:14-cv-376 (N.D. Cal.). Paper 7, 2. Patent Owner also identifies two petitions for inter partes review of other related patents of Patent Owner: IPR (U.S. Patent No. 8,504,628), IPR (U.S. Patent No. 7,966,372). Id. Patent Owner also identifies three petitions for covered business method review of other related patents of Patent Owner: CBM (U.S. Patent No. 8,224,913), CBM (U.S. Patent No. 8,209,389), and CBM (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 199 patent The 199 patent relates generally to a system and method for verifying delivery and content of an electronic message. Ex. 1001, 1: In particular, the 199 patent relates to a system and method of later providing proof regarding the delivery and content of an message. Id. at 1: According to the 199 patent, there was a need for an 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 3

4 convenience and speed as conventional , and which can be operated economically by a service provider. Id. at 2:64-3:4. To address this need, the 199 patent discloses an electronic message system that creates and records a digital signature of each electronic message sent through the system. Id. at 3: Figure 1 is reproduced below: Figure 1 is a system diagram of a first embodiment, wherein outgoing s are registered according to the present invention. Id. at 6: 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: The method of sending registered messages involves three parts: (1) preprocessing; (2) transmission; and (3) post-processing. Id. at 6:

5 Pre-processing During pre-processing of a message, 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: 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 the destination s mail server, and the delivery status of the destination (e.g., UNSENT, DELIVERED, UNDELIVERABLE). Id. at 6:62-7:37. The 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 sent by a recipient s MTA that notifies the nominal sender of the message that various events have occurred. Id. at 8: 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: MTAs that conform to the ESMTP can send notices of success and failure in the delivery of a message. Id. at 8: These Delivery Status Notifications (DSNs) are s 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: The 199 patent uses the term DSN to refer to any MTA generated message relating to the status of a received message. Id. at 8:

6 In order to elicit a Read Receipt from compliant MUAs, RPost server 14 includes certain headers in the header section of the message. Id. at 9:6-8. Because the method of the 199 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: 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:4-67. 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:1-4. 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:4-6. 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: 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: 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 6

7 sender of the message with an ESMTP DSN if the delivery to the addressee succeeds or fails. Id. at 12: 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: Whether the connection is SMTP or ESMTP, RPost server 14 will record the entire protocol dialogue between the two servers. Id. at 12: 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 for the recipient domain name. Id. at 11: 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 . Id. at 12: According to the 199 patent, this is an important advantage over other methods that rely only on ESMTP DSNs to prove delivery. Id. at 12: Post-processing MTA DSNs will be returned to the RPost addresses constructed as described above. Id. at 13: By parsing these addresses, the system can identify the message and the recipient that prompted the DSN notification. Id. at 13: 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: 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: Delivery receipts are 7

8 s sent to the original sender of the Registered message. Id. at 14: MUAs that are returned to the common RPost address (e.g., ) are passed on to the sender for his own evaluation in a form that can be authenticated by RPost. Id. at 15:53-16:22. In the event that the originator of a message later requires evidence that an was sent, delivered, or read, the originator presents the receipt(s) for the message to the operators of the RPost system. Id. at 16: RPost can then provide authentication, verification, and confirmation of the information contained within the receipt. Id. at 17: C. Illustrative Claim Of the challenged claims, claims 1, 9, and 17 are independent. Claim 1 is reproduced below: 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 the message at the server from the sender; transmitting the message to the recipient; 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; [] 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; and transmitting, before any authentication of the message, a copy of the first information to the sender from the server. 8

9 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 , IEEE, ( CEEM ) Bahreman, Alireza, and J. D. Tygar, Certified electronic mail, MS thesis, Carnegie Mellon University, ( CEM ) Ex Ex Feldbau WO 97/08869 Mar. 6, 1997 Ex E. The Asserted Grounds of Unpatentability Petitioner argues that the challenged claims are unpatentable based upon the following grounds: Reference(s) Basis Claims challenged CEEM , 9-11, and CEM , 6, 9-15, and Feldbau CEM and Feldbau 103 4, 5, 7, 8, and 16 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 (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). 9

10 For purposes of this decision, we construe the following claim terms and need not construe expressly any of the other claim terms at this time. 1. indication of the failure to deliver the message to the recipient (claims 1 and 17) / indication of failure to deliver the message to the recipient processor (claim 9) Petitioner proposes that these phrases be construed to encompass[] both error or success codes from servers, and receipt acknowledgements from the recipient of the message, such as clicking a link in an . Pet As support for its proposed construction, Petitioner cites to Patent Owner s infringement allegations (Pet. 7 (citing Ex. 1008, 22, 33)), but does not cite to the Specification. Patent Owner reserves the right to contest Petitioner s proposed construction of this phrase, but does not propose an alternative construction. Prelim. Resp. 5. This phrase requires an indication that the message was not delivered to the recipient. Petitioner s proposed construction encompasses indications that the message was delivered to the recipient (i.e., success codes and receipt acknowledgements) and is, therefore, overly broad. On this record, and for purposes of this Decision, we construe this phrase to encompass indications that the message was not delivered to the recipient, and to exclude indications that the message was delivered by the recipient (i.e., success codes or receipt acknowledgements). 2. at least a portion of a data transport protocol dialog (claims 1 and 17) / at least a portion of the transport protocol dialog (claim 9) Petitioner proposes that at least a portion of a [data] transport protocol dialog be construed to mean any information included in messages used for transmitting electronic mail messages from a first mail agent to a second mail agent. Pet As support for its proposed 10

11 construction, Petitioner notes that the 199 patent identifies two particular mail transport protocols i.e., SMTP and ESMTP each having its respective mail transport dialog, and that the 199 patent teaches that this dialogue will include protocol messages in which, among other things, the destination server identifies itself, grants permission to upload a message for a named recipient, and acknowledges that the message was received. Pet. 8-9 (quoting Ex. 1001, 12:63-13:2). Petitioner also argues that the 199 patent does not define this term, and does not teach what portion of the mail transport protocol dialog should be stored other than to describe them as transcripts, summaries, or abstractions of the transcripts. Pet. 9. Patent Owner argues that Petitioner s proposed construction of at least a portion of a [data] transport protocol dialog, is overly broad because it allows an message itself to possibly satisfy the claim element, and therefore essentially eliminates a limitation of the claim. Prelim. Resp Patent Owner proposes that this term be construed to mean data including a sequence of at least one command and at least one response exchanged between devices during transmission of the message from the server to the recipient. Id. at 6. We agree with Patent Owner that Petitioner s construction is overly broad insofar as it requires information from only the message itself, rather than information from the mail transport protocol dialog. The 199 patent describes two primary mail transport protocols: SMTP and ESMTP. The 199 patent describes an (E)SMTP dialogue between the sender s MTA and the recipient s MTA during which the message is delivered. See, e.g., Ex. 1001, 11:45-51, 12:1-4, 12: Accordingly, a person of ordinary skill in the art would understand at least a portion of a mail transport 11

12 protocol dialogue to include information from the dialogue between the MTAs (e.g., an SMTP command or an SMTP reply), not merely information from the message itself. However, because the claim requires only at least a portion, we do not agree with Patent Owner that it requires at least one command and at least one response. Prelim. Resp. 6. On this record, and for purposes of this Decision, we construe this term to mean at least one mail transport protocol command or at least one mail transport protocol reply. B. Claims 1-3, 9-11, and Anticipation by CEEM Petitioner argues that claims 1-3, 9-11, and are unpatentable under 35 U.S.C. 102(b) as anticipated by CEEM. Pet In support of this ground of unpatentability, Petitioner relies upon the Declaration of Dr. Clark. Id. (citing Ex , 55, 56, 59-92). 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. The protocol consists of four main elements: (1) a trusted third party, represented by the Office (EO); (2) the originator; (3) the recipient; and (4) the communication medium. Id. The EO is a third party server that provides the handling service in an electronic manner. Id. Figure 2 is reproduced below. 12

13 Figure 2 shows the integration of the EO into the existing Internet architecture. Id. The EO server implements the Security Policies to process requests for certified 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 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 Form (CEF) from the EO. Id. at 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 then send the signed message to Bob. Id. 13

14 Analysis In light of the arguments and evidence, Petitioner has not established a reasonable likelihood that claims 1-3, 9-11, and are unpatentable as anticipated by CEEM. Independent claim 1 recites, receiving at the server from the recipient an indication of the failure to deliver the message to the recipient. Independent claims 9 and 17 recite limitations commensurate in scope. Petitioner relies upon CEEM s disclosure that, if Bob refused to receive the message within a specific time, the EO will send a proof of undelivered message to Alice, and Dr. Clark s testimony that [o]ne of ordinary skill would understand that the EO receives an indication of receipt from Bob. Pet. 16 (citing Ex. 1009, 16; Ex ); see also id. at 19-20, Patent Owner argues that CEEM does not disclose this limitation because the EO never receives an indication of failure from Bob. Prelim. Resp We agree with Patent Owner. Petitioner s contentions are based upon its proposed claim construction that encompasses success codes, which we declined to adopt for the reasons discussed above. CEEM discloses that the EO waits a specific time for Bob to return the signed CEF and, only if it receives nothing, does it send a proof of undelivered message. Ex. 1009, 16. Thus, the EO does not receive an indication of failure; it infers a failure based upon not receiving anything from Bob. Accordingly, on the record before us, we are not persuaded that CEEM discloses this limitation. Conclusion We are not persuaded that Petitioner has established a reasonable likelihood that it would prevail in showing that claims 1-3, 9-11, and are unpatentable as anticipated by CEEM. 14

15 C. Claims 1-3, 6, 9-15, and Anticipation by CEM Petitioner argues that claims 1-3, 6, 9-15, and are unpatentable under 35 U.S.C. 102(b) as anticipated by CEM. Pet In support of this ground of unpatentability, Petitioner relies upon the Declaration of Paul Clark, DSc. ( Dr. Clark ). Id. (citing Ex ). 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. 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 15

16 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-3, 6, 9-15, and are unpatentable as anticipated by CEM. Independent claim 1 recites, receiving at the server from the recipient an indication of the failure to deliver the message to the recipient. Independent claims 9 and 17 recite limitations commensurate in scope. Petitioner relies upon CEM s disclosure that, Rob [recipient] signs a receipt corresponding to the received ciphertext and sends the receipt to the postmaster [server]. Pet. 28 (citing Ex. 1010, 6); Ex ); see also id. at 32-33, Patent Owner argues that CEM does not disclose this limitation because CEM does not disclose an indication of failure; instead, it waits until it receives an indication of successful delivery to Rob, and continues to retransmit the message until such an indication is received. Prelim. Resp We agree with Patent Owner. Petitioner s contentions are based upon its proposed claim construction that encompasses success codes, which we declined to adopt for the reasons discussed above. Petitioner identifies nothing in CEM disclosing an indication of failure. Accordingly, on the record before us, we are not persuaded that CEM discloses this limitation. 16

17 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 independent claims 1, 9, and 17 are unpatentable as anticipated by CEM. Our determination concerning the insufficiency of the evidence applies equally to dependent claims 2, 3, 6, 10-15, and D. Claims 1-20 Anticipation by Feldbau Petitioner argues that claims 1-20 are unpatentable under 35 U.S.C. 102(b) as anticipated by Feldbau. Pet In support of this ground of unpatentability, Petitioner relies upon the Declaration of Dr. Clark. Id. (citing Ex ). Feldbau (Ex. 1013) Feldbau describes a method and apparatus for authenticating the dispatch and the contents of dispatched information. Ex. 1013, 1: Figure 7 is reproduced below. 17

18 Figure 7 is a block diagram that illustrates system 700 and message dispatch and authentication service 750 in accordance with a preferred embodiment of Feldbau. Id. at 30:35-31:2. Sender 701 provides message 702 and address 704 of recipient 799 to message dispatch and authentication service 750. Id. at 31:2-4. [S]ervice 750 forwards the message 701 to the recipient 799 using the address 704. Id. at 31: [S]ervice 750, preferably after assuring that the message has been successfully delivered, adds (e.g., appends) a dispatch time indication 720 to message 702 and address 704, as well as information 708 indicating the 18

19 success (or failure) of the message delivery. Id. at 31: Additional dispatch information elements, such as a sequential dispatch number, the sender, recipient, and the service identification information may also be added. Id. at 31: Service 750 then associates the above data elements by, e.g., generating their fingerprint, which is then signed using service 750 s private key 752 to produce the service s signature 742. Id. at 32:1-4. Service 740 then provides back to sender 701 a service s generated certificate 740 comprising the service s signature 742 and, optionally, various dispatch information elements from which signature 742 has been generated. Id. at 32:6-10. According to Feldbau, there is no need to provide message 702 and address 704 with certificate 740, since sender 701 already has message 702 and address 704. Id. at 32: A record of certificate 740 can be kept with service 750 and a copy of certificate 740 can be provided for storage to one or more trustees. Id. at 33:9-12. Analysis In light of the arguments and evidence, Petitioner has not established a reasonable likelihood that claims 1-8 are unpatentable as anticipated by Feldbau. Petitioner has demonstrated a reasonable likelihood that it will prevail with respect to challenged claims 9-20, as discussed below. Claims 1-8 Independent claim 1 recites transmitting, before any authentication of the message, a copy of the first information to the sender from the server. Petitioner relies upon Feldbau s disclosure that service 750 provides back to the sender 701 a service s generated certificate 740 comprising the service s signature 742 and optionally various dispatch 19

20 information elements from which it has been generated. Pet. 44 (citing Ex. 1013, 32:6-10; Ex ). That disclosure in Feldbau, however, relates to an embodiment that is not cited for all of the other elements of claim 1. Specifically, Petitioner cites to the embodiment of Figure 7 only for elements [1.P], [1.1], [1.2], and [1.6]. Petitioner cites to the embodiments of Figure 2 for elements [1.P], [1.1], [1.2], [1.4], [1.5], and [1.6], and cites to the embodiment of Figure 3 for element [1.3]. Feldbau, however, describes the embodiment of Figure 7 as an alternative embodiment to that of Figure 2. Ex. 1013, 9:9-11. For anticipation, it is not enough that the prior art reference discloses multiple, distinct teachings that the ordinary artisan might somehow combine to achieve the claimed invention. See In re Arkley, 455 F.2d 586, 587 (Fed. Cir. 1972) ( [T]he [prior art] reference must clearly and unequivocally disclose the claimed [invention] or direct those skilled in the art to the [invention] without any need for picking, choosing, and combining various disclosures not directly related to each other by the teachings of the cited reference. ). Even if we were to ignore the citations to the embodiment of Figure 7, we would still not be persuaded that the embodiment of Figure 2, and the similar embodiment of Figure 3, discloses every element of independent claim 1. Specifically, for claim element [1.6] ( transmitting, before any authentication of the message, a copy of the first information to the sender from the server. ), Petitioner cites to column 15, lines 12 to 17, of Feldbau. That passage, however, merely describes information being associated and stored; it does not describe anything being transmitted. 20

21 Claims 9-20 Independent claim 9 recites, a server displaced from the originating processor and the recipient processor, the server capable of being configured by software commands []. Petitioner relies upon Feldbau s disclosure of authenticator 70 displaced from sending transceiver 42 and receiving transceiver 46. Pet We are persuaded that Petitioner s citations support Petitioner s contentions. Independent claim 9 also recites receive a message from the originating processor and to transmit the message to the recipient processor. Petitioner refers to its analysis of elements [1.1] and [1.2]. Pet. 49. For elements [1.1] and [1.2], Petitioner relies upon Feldbau s disclosure that authenticator 70 receives the transmitted information 60 and the destination address 62 from sending transceiver 42, and transmits it to receiving transceiver 46 using destination address 62. Pet. 42. We are persuaded that Petitioner s citations support Petitioner s contentions. Independent claim 9 also recites receive an indication of failure to deliver the message to the recipient processor and a transport protocol dialog generated by the electronic mail system during transmission of the message from the server to the recipient processor. Petitioner relies upon Feldbau s disclosure of a transmission completion indication 64 that provides information regarding the success of the transmission and is obtained from the communication protocol [20] used by the transceiver 76. Pet. 49. Patent Owner argues that Petitioner does not show that transmission completion indication 64 is generated during transmission of the message from the server to the recipient. Prelim. Resp Feldbau discloses, however, that transmission completion indication 64 is obtained from the 21

22 communication protocol [20]. Ex. 1013, 14: Moreover, as Patent Owner points out, the transmission completion indication 64 may indicate success ( TRANSMISSION OK ) or error ( ERROR ). Prelim. Resp On this record, we are persuaded that Petitioner s citations support Petitioner s contentions. Independent claim 9 recites, generate a first information from the at least a portion of the transport protocol dialog generated by the electronic mail system during transmission of the message from the server to the recipient processor. Petitioner relies upon Feldbau s dispatch information as the at least a portion of the transport protocol dialog. Pet. 49; Ex Petitioner relies upon Feldbau s disclosure that 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. Pet (citing Ex. 1013, 15:12-17, 17:23-25; Ex ). Thus, Feldbau discloses generating the associated information from the dispatch information. On this record, we are persuaded that Petitioner s citations support Petitioner s contentions. Conclusion We are persuaded that Petitioner has established a reasonable likelihood that it would prevail in showing that independent claims 9 and 17 are unpatentable as anticipated by Feldbau. We are also persuaded by Petitioner s contentions with respect to dependent claims and We are not persuaded that Petitioner has established a reasonable likelihood that it would prevail in showing that independent claim 1, or dependent claims 2-8, are unpatentable as anticipated by Feldbau. 22

23 E. Claims 4, 5, 7, 8, and 16 Obviousness over CEM and Feldbau Petitioner argues that claims 4, 5, 7, 8, and 16 are unpatentable under 35 U.S.C. 103(a) as obvious over CEM and Feldbau. Pet In support of this ground of unpatentability, Petitioner relies upon the Declaration of Dr. Clark. Id. (citing Ex , , 224, and 226). Analysis In light of the arguments and evidence, Petitioner has established a reasonable likelihood that claim 16 is unpatentable as obvious over CEM and Feldbau. Petitioner has not established a reasonable likelihood that claims 4, 5, 7, and 8 are unpatentable as obvious over CEM and Feldbau. Claims 4, 5, 7, and 8 Dependent claims 4, 5, 7, and 8 depend from independent claim 1. As discussed above, we are not persuaded that either CEM or Feldbau disclose all of the limitations of independent claim 1. For this ground, Petitioner does not argue that any of the limitations of claim 1 are obvious; Petitioner addresses only the additional limitations recited in the dependent claims. Thus, Petitioner s obviousness arguments do not cure the deficiencies of CEM and Feldbau with respect to claim 1. Claim 16 Dependent claim 16 depends from independent claim 9. Dependent claim 16 recites wherein the first information generated by the server includes a time the message was transmitted to the recipient processor. Petitioner refers to its analysis of claim element [7.1]. Pet. 60 (citing Ex ). For claim element [7.1], Petitioner relies upon CEM s teaching to timestamp the message before applying the hash function, and 23

24 upon Feldbau s teaching of a function executor 102 that has means for inputting a time indication generated by a secure time generator 104. Pet. 59 (citing Ex. 1010, 10; Ex. 1013, 25:33-26:2). Dr. Clark testifies that a person of ordinary skill in the art would have been motivated to send a time of transmission of the message to the recipient so that the sender has additional proof of when the PM transmitted the CEM to Rob (recipient). Ex We credit the testimony of Dr. Clark and, on this record, are persuaded that Petitioner s citations support Petitioner s contentions. Conclusion We are persuaded that Petitioner has established a reasonable likelihood that it would prevail in showing that claim 16 is unpatentable as obvious over CEM and Feldbau. We are not persuaded that Petitioner has established a reasonable likelihood that it would prevail in showing that claims 4, 5, 7, and 8 are unpatentable as obvious over CEM and Feldbau. III. CONCLUSION For the foregoing reasons, we determine that the information presented in the Petition establishes that there is a reasonable likelihood that Petitioner would prevail in establishing the unpatentability of claims 9-20 of the 199 patent. Further, we determine that Petitioner has not demonstrated a reasonable likelihood that it would prevail in establishing that claims 1-8 of the 199 patent are unpatentable The Board has not made a final determination on the patentability of any challenged claims. 24

25 IV. ORDER ORDERED that pursuant to 35 U.S.C. 314, an inter partes review is hereby instituted on the following grounds: 1. Claims 9-20 under 35 U.S.C. 102 as anticipated by Feldbau; 2. Claim 16 under 35 U.S.C. 103 as obvious over CEM and Feldbau; FURTHER ORDERED that all other grounds raised in Petitioner s Corrected Petition are denied because they are deficient for the reasons discussed above; and FURTHER ORDERED that pursuant to 35 U.S.C. 314(d) and 37 C.F.R. 42.4, notice is hereby given of the institution of a trial on the grounds of unpatentability authorized above; the trial commences on the entry date of this decision. 25

26 For PETITIONER: Stuart P. Meyer, Esq. David D. Schumann FENWICK & WEST LLP For PATENT OWNER: Lewis E. Hudnell, III HUDNELL LAW GROUP P.C. John K. Fitzgerald FULWIDER PATTON LLP 26