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 Denying 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-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 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 (E.D. Tex.); RPost Holdings, Inc. et al v. Trend Micro Incorporated, 2:13-cv (E.D. Tex.); Sophos Incorporated v. RPost Holdings, Inc. et al, 1:13-cv (D. Mass.); and Trend Micro Incorporated v. RPost Holdings, Inc. et al, Case No. 3:13-cv (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 (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: IPR (U.S. Patent No. 7,966,372), IPR (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: 2

3 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 628 patent The 628 patent relates generally to a system and method for verifying delivery and content of an electronic message. Ex. 1001, 1: In particular, the 628 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 628 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 convenience and speed as conventional , 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: Figure 1 is reproduced below: 3

4 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: 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: 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 4

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 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 628 patent uses the term DSN to refer to any MTA generated message relating to the status of a received message. Id. at 8: In order to elicit a Reading 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 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:

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: 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 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:

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 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 628 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 s sent to the original sender of the Registered message. Id. at 14: 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 was sent, delivered, or read, the originator presents the 7

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: 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 , IEEE, ( CEEM ) Ex

9 Bahreman, Alireza, and J. D. Tygar, Certified electronic mail, MS thesis, Carnegie Mellon University, ( CEM ) Allman, Eric, SENDMAIL TM INSTALLATION AND OPERATION GUIDE, Version ( S89 ) Kent, Stephen T., Internet Privacy Enhanced Mail, 36 COMMUNICATIONS OF THE ACM (1993) ( Kent ) Ex Ex 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 S CEM S89, CEEM, and Kent 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). 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. 9

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 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 Patent Owner reserves the right to contest Petitioner s proposed construction of this phrase, but does not propose an alternative construction. Prelim. Resp 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: 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: 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 10

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 In support of this ground of unpatentability, Petitioner relies upon the Declaration of Paul Clark, DSc. ( Dr. Clark ). Id. (citing Ex , 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), 11

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: 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: 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: 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. 12

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 server software. Pet. 17 (citing Ex. 1013, SMM:08-13; Ex ). 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 (citing Ex 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 (citing Ex. 1013, SMM08:16; Ex ). 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 13

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 In support of this ground of unpatentability, Petitioner relies upon the Declaration of Paul Clark, DSc. ( Dr. Clark ). Id. (citing Ex , , 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. 14

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 15

16 indication. Petitioner does not cite CEM; it cites only to Dr. Clark s testimony. Pet. 25 (citing Ex ). Patent Owner argues that CEM does not disclose this element because Petitioner does not specify where this element is found in CEM. Prelim. Resp 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 (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 Although Dr. Clark testifies that CEM would transmit a message through a normal route of servers and communication links not passing through the postmaster (Ex ), 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 16

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 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 In support of this ground of unpatentability, Petitioner relies upon the Declaration of Dr. Clark. Id. (citing Ex , 87, 91-93, 96, 108, 109, , , , 193, 194, 201, ). 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 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. 17

18 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 send the signed message to Bob. Id. 18

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 systems, primarily Internet . 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 systems, PEM is designed to be transparent to MTAs, so that the existing 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 19

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 addressing. Id. Alternatively, if PEM is integrated into the UA, a message originator might identify recipients using either 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, 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 ). 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 ). Patent Owner argues that Kent does not teach this limitation. 20

21 Prelim. Resp 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. Accordingly, it is IV. ORDER 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. 21

22 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 22