throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`
`
`
`APPLE INC.,
`Petitioner
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner
`
`____________________
`
`Case IPR2019-00825
`U.S. Patent No. 9,762,397
`____________________
`
`
`
`
`
`PETITIONER APPLE INC.’S REQUEST FOR REHEARING OF
`DECISION DENYING INSTITUTION OF INTER PARTES REVIEW
`
`
`
`
`
`
`
`
`Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`

`

`Case IPR2019-00825
`U.S. Patent No. 9,762,397
`
`TABLE OF CONTENTS
`
`
`I.

`II.

`  Argument and Relief Requested ...................................................................... 1 III.
`
`Introduction ...................................................................................................... 1 
`Standard of Review .......................................................................................... 1 
`
`A.  RFC3104 itself discloses that messages sent from host Y are sent to
`address Na of RSIP server N. ..................................................................... 2 
`B.  The Board misapprehended the evidence relied on by the Petition and Dr.
`Goldschlag. ................................................................................................. 4 
`
`  Conclusion ....................................................................................................... 7 VII.

`
`
`
`- i -
`
`

`

`Case IPR2019-00825
`U.S. Patent No. 9,762,397
`
`
`I.
`
`Introduction
`
`Apple Inc. respectfully requests rehearing of the Board’s November 6, 2019
`
`decision denying institution of inter partes review of U.S. Patent No. 9,762,397.
`
`Paper 7 (“DI”). In its decision, the Board asserted that “RFC3104 does not describe
`
`any message ever being sent from address Nb to address Na,” and “Dr. Goldschlag
`
`does not explain how RFC3104’s ‘tunneling’ operation results in the understanding
`
`that a message sent to RSIP server N via address Nb is also sent to address Na.”
`
`DI, 11-12. The Board misapprehended the evidence relied on by Dr. Goldschlag to
`
`support his opinion. In particular, a message sent from host Y to host X in
`
`RFC3104 must necessarily flow through addresses Nb and Na of RSIP server N, as
`
`explained by the Petition and Dr. Goldschlag’s declaration.
`
`
`II.
`
`Standard of Review
`
`“A party dissatisfied with a decision may file a request for rehearing,
`
`without prior authorization from the Board.” 37 C.F.R. § 42.71(d). The “burden of
`
`showing a decision should be modified lies with the party challenging the
`
`decision,” and the request “must specifically identify all matters the party believes
`
`the Board misapprehended or overlooked, and the place where each matter was
`
`previously addressed in a motion, an opposition, or a reply.” Id.
`
` Argument and Relief Requested
`III.
`The Board based its institution denial on Apple’s alleged failure to
`
`demonstrate that RFC3104 renders obvious claim 1’s recitation of “the
`
`
`
`- 1 -
`
`

`

`Case IPR2019-00825
`U.S. Patent No. 9,762,397
`intermediate computer receiving a secure message having a first source address
`
`sent to an address of the intermediate computer” and “the intermediate computer
`
`sending the secure message in the secure connection to the destination address by
`
`using the address of the intermediate computer as a second source address.” DI,
`
`10-13. The Board respectfully misapprehended the evidence cited in the Petition,
`
`which shows that messages sent from host Y to host X in RFC3104 must flow
`
`through both RSIP server N’s interface receiving packets at address Nb and RSIP
`
`server N’s interface sending packets from address Na. Thus, any packet sent to
`
`address Nb must also be sent to address Na. Apple respectfully requests that the
`
`Board grant rehearing and institute trial of claims 1 and 2 of the ’397 patent.
`
`A. RFC3104 itself discloses that messages sent from host Y are sent
`to address Na of RSIP server N.
`
`RFC3104 discloses that “IPsec packets from Y destined for X arrive at RSIP
`
`server N,” and “[i]f N is able to find a matching mapping, it tunnels the packet to X
`
`according to the tunneling mode in effect.” EX1004, 5; Pet., 38. This process is
`
`shown in the figure provided in RFC3104, as annotated in the Petition and Dr.
`
`Goldschlag’s declaration:
`
`
`
`- 2 -
`
`

`

`Case IPR2019-00825
`U.S. Patent No. 9,762,397
`
`
`
`EX1004, 2 (annotated); Pet., 38; EX1002, ¶103.
`
`As illustrated in the figure, RSIP server “N has two addresses: Na on address
`
`space A, and Nb on address space B. For example, A could be a private address
`
`space, and B the public address space of the general Internet.” EX1004, 3; Pet., 26;
`
`EX1002, ¶83.
`
`
`
`EX1004, 2 (annotated); Pet., 29; EX1002, ¶88.
`
`Importantly, the parties do not dispute that a message sent from host Y is
`
`received at address Nb of RSIP server N (e.g., N’s public interface), and then the
`
`same message is subsequently sent from address Na of server N (e.g., N’s private
`
`interface) to host X. See, e.g., Pet., 38-39, POPR, 18 (“RFC3104 teaches an RSIP
`
`Server N receiving a message at address Nb (from Host Y) and sending it out to
`
`RSIP Client X from address NA”). Thus, the message must flow through both
`
`
`
`- 3 -
`
`

`

`Case IPR2019-00825
`U.S. Patent No. 9,762,397
`RSIP server N’s interface for receiving packets (Nb) and RSIP server N’s interface
`
`for sending packets (Na). In other words, in order to be sent from address Na (i.e.,
`
`the point of connection between RSIP server N and address space A) the message
`
`must necessarily be received by RSIP server N’s interface sending the message
`
`from Na to X. And Dr. Goldschlag supported this assertion in his declaration by
`
`explaining how RFC3104 strongly alludes to this arrangement by disclosing that
`
`“Y sends IPsec packets … to X via address Nb using the negotiated SPI.” EX1004,
`
`5 (emphasis added); Pet., 28; EX1002, ¶87.
`
`B.
`
`The Board misapprehended the evidence relied on by the Petition
`and Dr. Goldschlag.
`
`The Board first takes issue that “RFC3104 does not describe any message
`
`ever being sent from address Nb to address Na, or that RSIP server N (the
`
`intermediate computer) sends or even can send any message from itself to itself.”
`
`DI, 11 (citing Patent Owner Preliminary Response (“POPR”), 15). But the Board
`
`misapprehended the arguments raised in the Petition. The Petition does not allege
`
`RSIP server N must actively send a message from itself to itself. Rather, the
`
`Petition explains that the message must necessarily flow from host Y to the RSIP
`
`interface for sending packets from address Na to host X “via address Nb,” as
`
`shown in the diagram below.
`
`
`
`- 4 -
`
`

`

`Case IPR2019-00825
`U.S. Patent No. 9,762,397
`
`Pet., 39; EX1002, ¶105.
`
`
`
`Put another way, a message sent from host Y to address Nb is also logically
`
`sent from host Y to address Na, so that the message can ultimately be sent from
`
`address Na to host X. Dr. Goldschlag’s declaration provides this argument using
`
`similar language: “[W]hen the RSIP server N receives a message sent from Y to X
`
`on the Nb interface, it must also be sent to the Na interface/address so that the Na
`
`interface/address can ultimately send the message to Client X. Otherwise, the
`
`message could not be sent via Na to the client X.” EX1002, ¶105; Pet., 39. Thus,
`
`the message is logically sent from host Y to both addresses Nb and Na, and from
`
`address Na to host X. Therefore, address Na meets the claim requirements of
`
`“receiving a secure message … sent to an address of the intermediate computer,”
`
`and “the intermediate computer sending the secure message in the secure
`
`connection to the destination address by using the address of the intermediate
`
`computer as a second source address.”
`
`
`
`- 5 -
`
`

`

`Case IPR2019-00825
`U.S. Patent No. 9,762,397
`The Board further states that “Dr. Goldschlag does not explain how
`
`RFC3104’s ‘tunneling’ operation results in the understanding that a message sent
`
`to RSIP server N via address Nb is also sent to address Na.” DI, 12 (citing
`
`EX1002, ¶¶105-06). This is true, but unnecessary. Rather, the Board
`
`misapprehended Dr. Goldschlag’s reliance on “tunneling.” RSIP’s “tunneling”
`
`process is merely referenced by Dr. Goldschlag to show that packets traveling from
`
`host X to host Y must flow through RSIP server N’s interface receiving packets at
`
`address Nb and RSIP server N’s interface sending packets from address Na, as
`
`explained above.
`
`In particular, Dr. Goldschlag’s testimony does not conclude that “a POSITA
`
`would have understood that a secure message sent to RSIP server N (i.e., the
`
`intermediate computer) via address Nb is also sent to address Na” because of the
`
`use of tunneling. EX1002, ¶106 (emphasis in original). Instead, Dr. Goldschlag’s
`
`reference to “RFC3104’s ‘tunneling’ operation” refers to the flow of packets from
`
`host Y to host X: “[W]hen, as explained above, such a secure message is
`
`ultimately sent to client X (second computer) using a second source address (i.e.,
`
`Na) instead of the first source address (Yb), it is using the same address of the
`
`intermediate computer (i.e., Na) that the message was sent to.” Id. (italics in
`
`original, bolding added).
`
`
`
`- 6 -
`
`

`

`Case IPR2019-00825
`U.S. Patent No. 9,762,397
`As such, the Board’s reference here to tunneling involving encapsulation of
`
`packets in a second header is irrelevant to Dr. Goldschlag’s and the Petition’s
`
`analysis, beyond the fact that packets are sent from address Na to host X as part of
`
`RFC3104’s tunneling operation. DI, 12 n.5. Accordingly, contrary to the Board’s
`
`assertion that Dr. Dr. Goldschlag’s opinions are unsupported, Dr. Goldschlag
`
`explicitly supports his opinions by specific and repeated cites to RFC3104. And as
`
`Dr. Goldschlag explains, the arrangement described in RFC3104 necessarily
`
`requires packets that are sent to interface Nb to also be sent to interface Na.
`
` Conclusion
`VII.
`For the reasons set forth above, Apple respectfully requests that the Board
`
`grant rehearing and institute trial of claims 1 and 2 of the ’397 patent.
`
`Respectfully submitted,
`STERNE, KESSLER, GOLDSTEIN & FOX P.L.L.C.
`
`/Daniel S. Block/
`
`
`Daniel S. Block (Reg. No. 68,395)
`Attorney for Petitioner
`
`
`
`
`
`
`
`
`
`
`
`
`Date: November 26, 2019
`1100 New York Avenue, N.W.
`Washington, D.C. 20005-3934
`(202) 371-2600
`
`
`
`- 7 -
`
`

`

`Case IPR2019-00825
`U.S. Patent No. 9,762,397
`CERTIFICATION OF SERVICE
`
`The undersigned hereby certifies that the above-captioned PETITIONER
`
`APPLE INC.’S REQUEST FOR REHEARING OF DECISION DENYING
`
`INSTITUTION OF INTER PARTES REVIEW was served via email on
`
`November 26, 2019, in its entirety upon the following counsel of record for Patent
`
`Owner:
`
`James T. Carmichael (Lead)
`Kenneth J. Weatherwax (Back-up)
`Stephen T. Schreiner (Back-up)
`Christopher J. Lee (Back-up)
`Richard B. Megley (Back-up)
`Brian E. Haan (Back-up)
`Ashley E. LaValley (Back-up)
`Patrick Maloney (Back-up)
`Jason C. Linger (Back-up)
`
`jim@carmichaelip.com
`weatherwax@lowensteinweatherwax.com
`schreiner@carmichaelip.com
`clee@leesheikh.com
`rmegley@leesheikh.com
`bhaan@leesheikh.com
`alavalley@leesheikh.com
`maloney@lowensteinweatherwax.com
`linger@lowensteinweatherwax.com
`
`MPH-IPRs@carmichaelip.com
`
`
`STERNE, KESSLER, GOLDSTEIN & FOX P.L.L.C.
`
`/Daniel S. Block/
`
`Daniel S. Block (Reg. No. 68,395)
`Attorney for Petitioner
`
`
`
`
`Date: November 26, 2019
`1100 New York Avenue, N.W.
`Washington, D.C. 20005-3934
`(202) 371-2600
`
`
`
`
`
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket