`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`APPLE INC.,
`Petitioner
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner
`____________________
`Case IPR2019-00823
`U.S. Patent No. 9,712,494
`____________________
`
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`UNDER 37 C.F.R. § 42.23
`
`
`
`
`
`
`
`
`Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`
`
`

`

`TABLE OF CONTENTS
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`Introduction ...................................................................................................... 1
`Claim Construction .......................................................................................... 1
`A. The Board should reject MPH’s improper construction of “mobile
`computer.” .................................................................................................. 1
`1. The ’494 patent does not does not address any capability of “a static
`secure connection” in its explanation of a “mobile computer.” ............ 3
`2. MPH and its expert Dr. Rouskas ignore that the ’494 patent uses the
`terms “mobile terminal” and “mobile host” in conjunction with
`computers that establish a “static secure connection.” ......................... 5
`B. MPH does not dispute that the prior art discloses a “unique identity,” and
`therefore this term need not be expressly construed. ................................. 8
`C. The term “substitute” does not need to be expressly construed. ................ 8
` Ground 1: The combination of RFC3104 and Grabelsky renders obvious
`claims 1-5 and 8-11. ........................................................................................ 8
`A. RFC3104 discloses a “mobile computer,” as recited in claim 1. ............... 8
`1. RFC3104 teaches the use of a laptop (i.e., “mobile computer”) that
`moves physical locations and changes networks. ................................. 9
`2. MPH’s arguments that a laptop cannot change addresses during the
`course of an ongoing RSIP connection are irrelevant. ........................ 11
`B. The combination of RFC3104 and Grabelsky teaches a “translation table
`[that] includes two partitions,” as recited in claim 4. ............................... 14
`C. The combination of RFC3104 and Grabelsky teaches that “the
`intermediate computer is configured to modify the translation table entry
`address fields in response to a signaling message sent from the mobile
`computer,” as recited in claim 9. .............................................................. 19
`D. The combination of RFC3104 and Grabelsky teaches that “the source
`address of the forwarded message is the same as the first network
`address,” as recited in claim 11. ............................................................... 22
`E. The combination of RFC3104 and Grabelsky renders obvious claims 2, 3,
`5, 8, and 10. .............................................................................................. 26
` Ground 2: The combination of RFC3104, Grabelsky, and Wagner renders
`obvious claims 6 and 7. ................................................................................. 26
`Conclusion ..................................................................................................... 27
`
`- i -
`
`
`
`
`
`
`
`
`
`
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`UPDATED EXHIBIT LIST
`
`Description
`U.S. Patent No. 9,712,494 B2 to Vaarala et al., issued Jul. 18, 2017
`(“the ’494 patent”)
`
`Declaration of David Goldschlag, Ph.D. (“Goldschlag Decl.”)
`
`Prosecution History of U.S. Patent No. 9,712,494 B2 (“Prosecution
`History”)
`
`RFC3104 - RSIP Support for End-to-end IPsec, The Internet Society
`(Oct. 2001) (“RFC3104”)
`
`Prosecution History of U.S. Patent No. 8,346,949 B2 (“’949 Patent
`Prosecution History”)
`
`U.S. Patent No. 7,032,242 B1 to Grabelsky et al., issued Apr. 18,
`2006 (“Grabelsky”)
`
`Wagner et al., Analysis of the SSL 3.0 Protocol, USENIX (Nov.
`1996) (“Wagner”)
`
`Declaration of Ms. Sandy Ginoza (“Ginoza Decl.”)
`
`Declaration of James L. Mullins Ph.D. (“Mullins Decl.”)
`
`Curriculum Vitae of James L. Mullins
`
`S. Frankel, “Demystifying the IPsec Puzzle,” Artech House, Inc.,
`2001 (“Frankel”)
`
`RSIP Support for End-to-end IPsec (RFC 3104), IETF Data Tracker
`(2000) (“IETF Data Tracker”)
`
`RFC2026 - The Internet Standards Process -- Revision 3 (Oct. 1996)
`(“RFC2026”)
`
`RFC2246 - The TLS Protocol Version 1.0 (Jan. 1999) (“RFC2246”)
`
`- ii -
`
`Exhibit No.
`
`1001
`
`1002
`
`1003
`
`1004
`
`1005
`
`1006
`
`1007
`
`1008
`1009
`1010
`
`1011
`
`1012
`
`1013
`
`1014
`
`
`
`
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`Description
`RFC2401 - Security Architecture for the Internet Protocol (Nov.
`1998) (“RFC2401”)
`
`RFC2402 - IP Authentication Header (Nov. 1998) (“RFC2402”)
`
`RFC2406 - IP Encapsulating Security Payload (ESP) (Nov. 1998)
`(“RFC2406”)
`
`RFC2409 - The Internet Key Exchange (IKE) (Nov. 1998)
`(“RFC2409”)
`
`RFC3102 - Realm Specific IP: Framework (Oct. 2001)
`(“RFC3102”)
`
`Zhang et al., “A Multu-Layer IPsec Protocol,” (Aug. 2000)
`(“Zhang”)
`
`Curriculum Vitae of David Goldschlag, Ph.D. (“Goldschlag CV”)
`
`Declaration of David Goldschlag, Ph.D., in Support of Petitioner’s
`Reply to Patent Owner’s Response (“Second Goldschlag Decl.”)
`
`Transcript of the Deposition of George N. Rouskas, Ph.D., May 7,
`2020 (“Rouskas Dep.”)
`
`Transcript of the Deposition of Michael S. Borella, Ph.D., May 18,
`2020 (“Borella Dep.”)
`
`Merriam-Webster’s Collegiate Dictionary, Eleventh Edition (2003)
`(“Merriam-Webster’s Dictionary”)
`
`Exhibit No.
`
`1015
`
`1016
`
`1017
`
`1018
`
`1019
`
`1020
`
`1021
`
`1022
`
`1023
`
`1024
`
`1025
`
`
`
`
`
`- iii -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`
`Introduction
`Patent Owner (“MPH”) presents a single argument in support of the
`
`patentability of the ’494 patent’s independent claim: that the prior art does not
`
`teach a “mobile computer,” as recited in claim 1 of the ’494 patent. This argument
`
`is premised on an improper and overly narrow construction of the term “mobile
`
`computer” which attempts to import numerous additional requirements into this
`
`basic term. The Board properly rejected similar attempts by MPH at the institution
`
`stage, and should continue to do so. A “mobile computer” is taught by RFC3104
`
`under any reasonable interpretation of the term, and thus, the Board should find
`
`independent claim 1 unpatentable.
`
`MPH’s arguments against the dependent claims fare no better. Again, MPH
`
`attempts to import requirements into the claims that do not exist and
`
`mischaracterizes the Petition’s arguments. For the reasons specified in the Petition
`
`and below, the Board should find the dependent claims unpatentable over the cited
`
`prior art.
`
` Claim Construction
`A. The Board should reject MPH’s improper construction of “mobile
`computer.”
`“mobile computer”
`MPH’s
`“a computer that moves from one network to another as
`Proposed
`opposed to a computer that is only capable of a static secure
`connection”
`Construction
`
`
`
`- 1 -
`
`

`

`Apple’s
`Proposed
`Construction
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`To the extent the Board determines this term needs to be
`construed:
`
`“a computer that is capable of moving between networks or
`physical locations”
`
`MPH proposes that the term “mobile computer” should be construed as “a
`
`computer that moves from one network to another as opposed to a computer that is
`
`only capable of a static secure connection.” POR, 10. While MPH contends that its
`
`construction “has been revised based on the Board’s guidance” in the institution
`
`decision, this construction imports essentially the same additional requirements
`
`into the claims that the Board already rejected at institution, namely that the
`
`“mobile computer” must be able to move while maintaining its secure connection.
`
`See DI, 10-11. Indeed, MPH similarly asserted in its POPR that “the claims should
`
`be construed to distinguish the claimed ‘mobile computer’ from a computer that is
`
`only capable of static connections.” POPR, 4. MPH’s expert also could not explain
`
`any substantive difference between MPH’s proposed construction prior to
`
`institution and its newly proposed construction aside from using different
`
`language. EX1023, Rouskas Dep., 11:16-19, 15:3-17:3. This overly-narrow
`
`construction is improper and should again be rejected. Superguide Corp. v.
`
`DirecTV Enters., Inc., 358 F.3d 870, 875 (Fed. Cir. 2004); E-Pass Techs., Inc. v.
`
`3Com Corp., 343 F.3d 1364, 1369 (Fed. Cir. 2003) (“[A]n inherent tension exists
`
`as to whether a statement is a clear lexicographic definition or a description of a
`
`
`
`- 2 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`preferred embodiment. The problem is to interpret claims ‘in view of the
`
`specification’ without unnecessarily importing limitations from the specification
`
`into the claims.”).
`
`1.
`
`The ’494 patent does not does not address any capability of
`“a static secure connection” in its explanation of a “mobile
`computer.”
`To support its proposed construction, MPH first points to the ’494 patent’s
`
`use of the terms “mobility” and “mobile terminal”:
`
`In this text, the term mobility and mobile terminal does not only mean
`physical mobility, instead the term mobility is in the first hand meant
`moving from one network to another, which can be performed by a
`physically fixed terminal as well.
`
`EX1001, 4:34-38. As Apple’s expert, Dr. Goldschlag, explains, this language is
`
`extremely broad. EX1022, Second Goldschlag Decl., ¶¶7-9. Consistent with
`
`Apple’s proposed construction (to the extent this term needs to be expressly
`
`construed), this passage states that these terms “not only mean physical mobility,”
`
`but also can describe a terminal (e.g., computer) that “move[s] from one network
`
`to another.” Id. Importantly, this is the complete extent of the meaning assigned to
`
`the terms “mobility” and “mobile terminal” in the ’494 patent. Id. And, as MPH’s
`
`expert Dr. Rouskas explains, the ’494 patent uses the terms “mobile terminal,”
`
`“mobile host,” and “mobile computer” to mean the same thing. EX1023, 163:10-
`
`164:15.
`
`
`
`- 3 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`MPH’s expert Dr. Rouskas also agreed with this interpretation in cross-
`
`examination, clarifying his understanding of the terms “mobile terminal” and
`
`“mobility” in this passage:
`
`Q. Okay. So I'll ask again, do you have an understanding of what the
`term “does not only mean,” how that affects, if at all, the
`interpretation of that sentence?
`. . .
`A. Right. So a physical mobility, that could be moving let’s say my
`laptop from one desk to another in the same room.
`Q. Right. So I guess what I'm asking is, wouldn’t you interpret what it
`says here to say the term “mobility” means not only that you can move
`it from, you know, one place in your room to the other, but it also
`means that moving from one network to another?
`. . .
`A. Well, yes, [t]hat’s what I understand what that sentence means,
`that mobility also means moving from one network to another.
`
`EX1023, 159:13-160:10 (emphasis added). Thus, even MPH’s own expert agreed
`
`with the ’494 patent’s broad use of the terms “mobility” and “mobile terminal,”
`
`which, on their own, do not suggest anything more than moving between networks
`
`and/or physical locations. EX1022, ¶¶10-11. Dr. Rouskas further conceded that he
`
`did not form an opinion on whether his proposed construction required the “mobile
`
`computer” to actually move, or just required the capability of moving—confirming
`
`an even broader understanding of the term. See EX1023, 17:6-20:3.
`
`
`
`- 4 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`Even more, MPH relied on a second expert, the first-named author of
`
`RFC3104 (Michael Borella), to opine on alleged issues of mobility in the context
`
`of RFC3104. See generally EX2010. Yet, on cross-examination, Dr. Borella
`
`similarly opined that his complete understanding of the term “mobile computer” in
`
`the context of the ’494 patent is a computer that “moves from one network to
`
`another.” EX1024, Borella Dep., 230:17-20. Hence, all of the parties’ experts agree
`
`that the term “mobile computer” means nothing more than moving (or the
`
`capability of moving) between networks or physical locations. EX1022, ¶12.
`
`2. MPH and its expert Dr. Rouskas ignore that the ’494 patent
`uses the terms “mobile terminal” and “mobile host” in
`conjunction with computers that establish a “static secure
`connection.”
`MPH further cites to other portions of the ’494 patent to support its proposed
`
`construction of “mobile computer,” attempting to differentiate the term from “a
`
`computer that is only capable of a static secure connection.” POR, 12-16; EX2002,
`
`¶83. These passages of the ’494 patent use the terms “mobile terminal” and
`
`“mobile host,” and as discussed above, MPH’s expert Dr. Rouskas explains that
`
`the ’494 patent uses the terms “mobile terminal,” “mobile host,” and “mobile
`
`computer” to mean the same thing. EX1023, 163:10-164:15. But both MPH and its
`
`expert Dr. Rouskas ignore that the terms “mobile terminal” and “mobile host” in
`
`these passages refer to computers that only establish a “static secure connection”—
`
`
`
`- 5 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`directly contradicting MPH’s proposed construction that requires a “mobile
`
`computer” to maintain a secure connection when moving.
`
`For example, MPH cites to the ’494 patent at 4:60-64, which states,
`
`“Standard IPSec does not work well in the scenario. Since IPSec connections are
`
`bound to fixed addresses, the mobile terminal must establish a new IPSec
`
`connection from each point of attachment.” POR, 14 (citing EX1001, 4:60-64
`
`(emphasis added)). As Apple’s expert explains, this passage plainly uses the term
`
`“mobile terminal” in conjunction with a computer establishing a static IPSec
`
`connection each time the computer connects to a network. EX1022, ¶¶13-14.
`
`MPH cites also to the ’494 patent at 4:15-27, which states that “IPSec is
`
`intended to work with static network topology, where hosts are fixed to certain
`
`subnetworks . . . . If IPSec is used with a mobile host, the IKE key exchange will
`
`have to be redone from every new visited network.” POR, 13 (citing EX1001, 4:15-
`
`27 (emphasis added)). Again, this passage plainly uses the term “mobile host” in
`
`conjunction with a computer reestablishing static IPSec connections when moving
`
`rather than maintaining them. EX1022, ¶15.
`
`During cross-examination, Dr. Rouskas was asked about these passages in
`
`relation to his and MPH’s proposed construction of “mobile computer.” EX1023,
`
`164:16-178:12. Although Dr. Rouskas asserted that he “considered the entire
`
`specification” when forming his construction of “mobile computer,” id., 173:8-18,
`
`
`
`- 6 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`Dr. Rouskas repeatedly asserted that he had not formed an opinion on what the
`
`terms “mobile terminal” and “mobile host” mean as they are used in these passages
`
`of the ’494 patent, id., 174:4-177:4. For example, when asked, “Do you have an
`
`opinion on what the terms ‘mobile terminal’ and ‘mobile host’ mean as those terms
`
`are used in the background sections of the ’494 and the ’502 patents?” Dr. Rouskas
`
`responded, “I did not form an opinions [sic] on this -- on the terms.” Id., 175:12-
`
`176:1. Thus, MPH’s expert merely chose to characterize portions of the ’494
`
`patent specification in a way that suited MPH’s interests, rather than to properly
`
`consider the specification as a whole. And, again, MPH and its expert specifically
`
`cited to these portions of the ’494 patent specification to support its proposed
`
`construction. POR, 12-16; EX2002, ¶83.
`
`Recognizing Dr. Rouskas’s critical failure to consider the ’494 patent’s
`
`usage of “mobile terminal” and “mobile host” when forming his construction of
`
`“mobile computer,” MPH’s counsel attempted to reverse Dr. Rouskas’s testimony
`
`on redirect. Specifically, counsel for MPH asked Dr. Rouskas whether he meant
`
`“to say that the term ‘mobile computer’ as it’s used in the claims means the same
`
`thing as ‘mobile host’ as it’s discussed in the background of the invention in the
`
`’494 and ’502 patents.” EX1023, 179:18-22. Unsurprisingly, Dr. Rouskas
`
`responded that he “did not mean to say that.” Id., 180:1-2. However, significantly
`
`undermining the credibility of his testimony, Dr. Rouskas admitted that he
`
`
`
`- 7 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`discussed his answers to the questions on redirect with counsel during the break.
`
`Id., 181:9-21. Accordingly, the Board should not give credence to this arranged
`
`testimony.
`
`For these reasons, MPH’s overly-narrow construction of the term “mobile
`
`computer” should once again be rejected. EX1022, ¶16.
`
`B. MPH does not dispute that the prior art discloses a “unique
`identity,” and therefore this term need not be expressly construed.
`There is no dispute that the prior art in this proceeding discloses a “unique
`
`identity,” as recited in the claims. See POR, 20 (“Patent Owner does not dispute
`
`that some form of a unique identity is found in the primary reference.”). Therefore,
`
`the Board need not expressly construe this term for purposes of this proceeding.
`
`C. The term “substitute” does not need to be expressly construed.
`Apple does not believe the term “substitute” needs to be expressly construed
`
`for purposes of this proceeding.
`
` Ground 1: The combination of RFC3104 and Grabelsky renders
`obvious claims 1-5 and 8-11.
`A. RFC3104 discloses a “mobile computer,” as recited in claim 1.
`MPH’s entire argument against claim 1 is premised on its incorrect
`
`construction of the term “mobile computer.” POR, 25-51. As discussed above, this
`
`construction should be rejected. As explained in the Petition and below, the
`
`combination of RFC3104 and Grabelsky teaches a “mobile computer” under any
`
`reasonable interpretation of the term.
`
`
`
`- 8 -
`
`

`

`1.
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`RFC3104 teaches the use of a laptop (i.e., “mobile
`computer”) that moves physical locations and changes
`networks.
`As explained in the Petition, RFC3104 discloses a “Roadwarrior scenario” in
`
`which “a remote user with a laptop gains access to the Internet, perhaps by using
`
`PPP or DHCP. The user wants to access its corporation private network.” EX1004,
`
`16 (emphasis added); Pet., 33-35
`
`RFC3104, 16.
`
`
`
`In this scenario, both parties and their experts agree that a POSITA would
`
`have understood that the laptop moves from one network to another, and is thus a
`
`“mobile computer.” Pet., 20, 33-35 (citing EX1002, ¶¶93-95); POR, 28-29 (citing
`
`EX2002, ¶97) (“[A] POSITA would understand that a businessperson on the road
`
`with a laptop can be expected to connect to different networks from different
`
`places (e.g., hotel, airport, office) . . . .”). Indeed, this is consistent with the
`
`ordinary meaning of the term “road warrior,” i.e., “a person who travels frequently
`
`especially on business.” EX1025, Merriam-Webster’s Collegiate Dictionary, 1077;
`
`
`
`- 9 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`EX1022, ¶19. Further, during cross-examination, MPH’s expert Dr. Rouskas
`
`agreed that RFC3104’s “Roadwarrior scenario does contemplate a scenario where
`
`the laptop would be moved to different locations, and it would reconnect back to
`
`the server” with a different IP address. EX1023, 152:10-153:9 (emphasis added).
`
`And MPH’s other expert, Dr. Borella, conceded that this scenario (i.e., a computer
`
`that disconnects from one network, moves to another network, and then reconnects
`
`using a second network) would meet his definition of “mobile computer.” EX1024,
`
`224:9-225:4. Thus, both parties agree that the laptop used in RFC3104’s
`
`Roadwarrior scenario is “mobile” in that it moves from one network to another.
`
`EX1022, ¶20.
`
`With this understanding, the Petition explains that “a POSITA would have
`
`understood that in the context of the ‘Roadwarrior scenario,’ the computer
`
`connected to the public Internet would be a ‘laptop [i.e., “mobile computer”] [that]
`
`gains access to the Internet.’” Pet., 34 (citing EX1002, ¶95). MPH’s expert Dr.
`
`Borella, a co-author of RFC3104, also agreed that the “Roadwarrior scenario” can
`
`be reversed, meaning “Host Y can initiate the connection instead of Host X.”
`
`EX1024, 248:9-14; EX1004, 16. This testimony renders irrelevant Dr. Borella’s
`
`distinctions with regard to which host in the Roadwarrior scenario is an RSIP client
`
`(see EX2010, ¶60), since the Roadwarrior scenario contemplates both scenarios in
`
`which either host X or host Y plays the role of the RSIP client. EX1022, ¶¶20-24.
`
`
`
`- 10 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`The Roadwarrior’s reversed scenario further aligns precisely with the “core”
`
`diagram of RFC3104 in which the RSIP client initiating the connection is on the
`
`internal private network, and the IPSec peer is connected to the Internet. See Pet.,
`
`33-35 (discussing the Roadwarrior’s reversed scenario).
`
`
`
`EX1004, 2 (annotated); EX1022, ¶23.
`
`Hence, there is no reasonable dispute that RFC3104 contemplates the use of
`
`a “mobile” laptop involved in a secure RSIP connection, as illustrated by
`
`RFC3104’s “Roadwarrior scenario.” EX1022, ¶25.
`
`2. MPH’s arguments that a laptop cannot change addresses
`during the course of an ongoing RSIP connection are
`irrelevant.
`Although MPH devotes 26 pages of argument in its POR to the “mobile
`
`computer” of the claims, MPH’s only objection to the prior art is that “a POSITA
`
`would not understand the laptop [of RFC3104] to be changing addresses during the
`
`course of an ongoing RSIP connection.” POR, 29 (emphasis added). This
`
`
`
`- 11 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`statement, and the remainder of MPH’s analysis, illustrates that MPH is still
`
`asserting that the claimed “mobile computer” must be able to move networks while
`
`maintaining its connection, the same argument that MPH put forth in its Patent
`
`Owner Preliminary Response and the Board previously considered. See DI, 9-11.
`
`As discussed in Section II.A, this attempt to import additional requirements into
`
`the term “mobile computer” is improper and inconsistent with the ’494 patent’s
`
`usage of the term. EX1022, ¶26.
`
`MPH further attempts to support this argument by alleging that the system of
`
`RFC3104 would become “inoperable” if any host changed address. POR, 29-30,
`
`34, 37-38, 45. But MPH misses the point. RFC3104’s laptop “moves” between
`
`networks (e.g., is a “mobile computer”) because it can disconnect from a first
`
`network and then reestablish an RSIP connection at a second network. Indeed,
`
`none of the experts—Dr. Borella, Dr. Rouskas, or Dr. Goldschlag—appear to
`
`dispute that point. EX1022, ¶¶27-28.
`
`Specifically, Dr. Borella admitted that a computer that connects from one
`
`network, disconnects, and reconnects to another network is a “mobile computer”:
`
`A. Okay so if I can reiterate this in my own words you would like to
`know whether the definition of mobile computer in paragraph 42 of
`my declaration includes a network -- excuse me -- includes a
`computer that disconnects from one network, moves to another
`
`
`
`- 12 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`network, and then reconnects using that network, that second network.
`Is that fair?
`MR. BLOCK: Yeah. That’s fair.
`A. Okay. Perhaps I’m over thinking this I haven’t specifically
`considered that scenario. But you do -- you are telling me that this
`hypothetical computer is moving from one network to another.
`MR. BLOCK: Yeah. That is correct.
`A. All right. In that case, in that case it falls within the definition I
`have provided here.
`
`EX1024, 224:9-225:4 (emphasis added); see also EX1023, 152:10-153:9 (MPH’s
`
`expert Dr. Rouskas testifying that such a scenario is contemplated by RFC3104).
`
`In other words, Dr. Borella conceded during cross-examination that a
`
`computer does not need to maintain a connection during its move to be considered
`
`a “mobile computer” within the context of the ’494 patent. Rather, the simple fact
`
`that the computer “move[s] from one network to another” makes the computer fall
`
`within Dr. Borella’s applied definition of “mobile computer,” as conceded by Dr.
`
`Borella. EX1024, 224:20-225:4; EX1022, ¶29. And, as discussed above, there is no
`
`dispute that RFC3104’s disclosed laptop computer would move from one network
`
`to another, reconnecting from different points of attachment with different IP
`
`addresses. See EX1023, 153:1-9. Therefore, Dr. Borella’s declaration testimony
`
`regarding alleged mobility issues of RFC3104 are immaterial to the requirements
`
`of the “mobile computer” in the challenged claims. See EX2010, ¶¶44-63.
`
`
`
`- 13 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`Accordingly, RFC3104 teaches a “mobile computer” within the context of
`
`the ’494 patent claims, consistent with the usage of the term in the ’494 patent
`
`specification.
`
`B.
`
`The combination of RFC3104 and Grabelsky teaches a
`“translation table [that] includes two partitions,” as recited in
`claim 4.
`MPH alleges that “[t]he Petition and Dr. Goldschlag’s testimony fail to
`
`articulate where the claimed two-partition translation table, and its recited details,
`
`are found in RFC3104 and Grabelsky.” POR, 61. But MPH mischaracterizes the
`
`Petition. In particular, the Petition explains that “Grabelsky discloses a table for
`
`mapping SPI values to a local destination address, as illustrated in Figure 21.” Pet.,
`
`45 (emphasis added).
`
`EX1006, Grabelsky, FIG. 21.
`
`
`
`The Petition further explains that “RFC3104 already discloses a ‘mapping’
`
`of the ‘minimum tuple of demultiplexing fields’ to a destination (e.g., the
`
`
`
`- 14 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`destination address of RSIP client X).” Pet., 46 (citing EX1004, 5; EX1002, ¶118)
`
`(emphasis added). Thus, “RFC3104 explicitly discloses a mapping, and Grabelsky
`
`supplies an efficient mapping technique in the form of a translation table.” Pet., 46;
`
`EX1022, ¶32.
`
`To implement such a mapping using a translation table as in Grabelsky, the
`
`Petition further provides that “[a] POSITA would have understood that this table
`
`would include two partitions, including: (1) values of the ‘demultiplexing fields’
`
`used in the packet sent from host Y to RSIP server N; and (2) the value of the
`
`destination address of the IPSec SA.” Pet., 53 (citing EX1002, ¶130). Indeed, this
`
`corresponds to the exact mapping described by RFC3104. EX1004, 5; EX1022,
`
`¶33. Thus, MPH’s argument that the Petition’s explanation “is not linked to
`
`supporting evidence,” POR, 61, ignores the explicit teachings of both RFC3104
`
`and Grabelsky.
`
`MPH’s only remaining dispute with respect to claim 4 is that the claim
`
`requires “that the second partition has more than one field.” POR, 59-61 (emphasis
`
`added). But MPH misinterprets the claim requirements, which do not recite “a
`
`plurality” of information fields. As Apple’s expert explains, a POSITA would have
`
`understood the language “the second partition containing information fields
`
`related to the connection over which the forwarded encrypted data payload is sent
`
`to the destination address” to simply refer to the type of fields that make up the
`
`
`
`- 15 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`second partition, not the number of fields that must be present. EX1022, ¶34. In
`
`other words, the information contained in the second partition must merely relate
`
`to “the connection over which the forwarded encrypted data payload is sent to the
`
`destination address.” Id. This is also consistent with the description in the ’494
`
`patent with respect to FIG. 3, in which the second partition relates to “the network
`
`connection between the intermediate computer and the second computer.”
`
`EX1001, 11:45-47.
`
`In any event, the Petition and Apple’s expert explain that “a POSITA would
`
`have been motivated to include more than the destination address of the IPSec SA
`
`in the second partition, for example also including the other ‘demultiplexing
`
`fields’ (i.e., the SPI and protocol) so that values of the first partition could simply
`
`be substituted with values of the second partition in the data packet sent from
`
`server N to host X.” Pet., 54 (citing EX1002, ¶132). Moreover, RFC3104 suggests
`
`a multitude of other fields that a POSITA would naturally have included in the
`
`second partition in addition to those examples provided in the Petition. EX1022,
`
`¶35.
`
`In particular, as discussed in the Petition, RFC3104 discloses an
`
`“ASSIGN_REQUEST_RSIPSEC message [that] is used by an RSIP client to
`
`request IPsec parameter assignments,” including fields such as “an IP address and
`
`SPIs.” Pet., 57 (citing EX1004, 7); EX1022, ¶36. In addition to IP addresses and
`
`
`
`- 16 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`SPI values, the complete list of parameters of the ASSIGN_REQUEST_RSIPSEC
`
`message are illustrated below:
`
`EX1004, 8.
`
`
`
`As MPH’s expert explains, “[t]he ASSIGN_REQUEST_RSIPSEC message
`
`is sent by Host X to request a binding such that Server N allocates resources for
`
`Host X to subsequently establish an IPSec secure connection.” EX2002, ¶110. The
`
`parameters of this binding are stored at RSIP server N and associated “with an
`
`RSIP host.” EX2004, RFC3103, 5 (defining “Binding” as “[a]n association of
`
`some combination of a local address, one or more local ports, a remote address,
`
`and a remote port with an RSIP host.”); EX1023, 107:6-10 (“[S]o the binding
`
`associates that particular tuple of resources with the host.”). RFC3103 further
`
`explains that “[t]his binding enables the RSIP gateway to correctly de-multiplex
`
`and forward inbound traffic generated by Y for X.” EX2004, 6. In other words, this
`
`
`
`- 17 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`binding forms the “mapping” to which RFC3104 refers when demultiplexing
`
`“IPsec packets from Y destined for X.” See EX1004, 5; EX1022, ¶37; Pet., 37-38.
`
`As disclosed in RFC3104, this binding includes numerous parameters
`
`associated with the RSIP client X (i.e., the client requesting parameter
`
`assignments), such as, for example, a “Lease Time” parameter. EX1004, 8. As
`
`RFC3103 explains, “[a] lease time is associated with each bind,” and “[t]he lease
`
`time parameter specifies the length, in seconds, of an RSIP host registration or
`
`parameter binding.” EX2004, 6, 13. Further, RFC3103 provides that a lease time
`
`“must be provided for every assignment” as part of the RSIP connection setup, and
`
`thus each binding would have an associated lease time. EX2004, 22; EX1022, ¶38.
`
`Thus, the “Lease Time” parameter is related to “the connection over which the
`
`forwarded encrypted data payload is sent to the destination address,” in other
`
`words the connection between RSIP client X and RSIP server N. EX1022, ¶38.
`
`And, since this binding is stored at the RSIP server N, a POSITA would
`
`have recognized that it would be logical to store the parameters of this binding
`
`together, especially those parameters specified on a per-binding bases such as
`
`“lease time.” For example, in the combination of RFC3104 and Grabelsky, these
`
`parameters could be stored in the translation table. Id., ¶39. In this case, it would
`
`have been obvious to include the assigned parameters in the table’s “second
`
`partition” so that the parameters could easily be retrieved based on RFC3104’s
`
`
`
`- 18 -
`
`

`

`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`“minimum tuple of demultiplexing fields.” EX1022, ¶39; EX1004, 5. Therefore,
`
`even if claim 4 were interpreted to require more than one field in each table
`
`partition, the combination of RFC3104 and Grabelsky teaches numerous fields that
`
`would be included. EX1022, ¶39.
`
`C. The combination of RFC3104 and Grabelsky teaches that “the
`intermediate computer is configured to modify the translation
`table entry address fields in response to a signaling message sent
`from the mobile computer,” as recited in claim 9.
`As an initial matter, as explained in the petition, a POSITA would have
`
`understood that “either RFC3104’s host Y or X could be (and often would be) a
`
`‘mobile computer,’ and that naturally, as a consequence of the host Y or X being a
`
`mobile computer, their address would change due to mobility of such a computer.”
`
`Pet., 33 (citing EX1002, ¶91). As discussed above, this is evidenced at least by
`
`RFC3104’s disclosure of a laptop in the “Roadwarrior” scenario, which all pa