UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`APPLE INC.,
`Petitioner
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner
`____________________
`Case IPR2019-00824
`U.S. Patent No. 9,712,502
`____________________
`
`
`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-00824
`U.S. Pat. No. 9,712,502
`
`
`
`
`
`
`
`Introduction ................................................................................................ 1
`Claim Construction ..................................................................................... 1
`A. The Board should reject MPH’s improper construction of “mobile
`computer.” .................................................................................................. 1
`1. The ’502 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 ’502 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. MPH does not dispute that the prior art discloses a “secure connection,”
`and therefore this term need not be expressly construed. .......................... 8
`Ground 1: The combination of RFC3104 and Grabelsky renders obvious
`
`claims 1-9. .................................................................................................................. 9
`A. RFC3104 discloses a “mobile computer,” as recited in claim 1. ............... 9
`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. ........................ 12
`B. The combination of RFC3104 and Grabelsky teaches that “the computer
`is configured to send a signaling message to the intermediate computer
`when the computer changes its address such that the intermediate
`computer can know that the address of the computer is changed,” as
`recited in claim 7. ..................................................................................... 14
`C. The combination of RFC3104 and Grabelsky teaches that “the computer
`is configured to send the signaling message encrypted,” as recited in
`claim 8. ..................................................................................................... 18
`D. The combination of RFC3104 and Grabelsky renders obvious claims 2-6
`and 9. ........................................................................................................ 21
`Ground 2: The combination of RFC3104, Grabelsky, and Wagner renders
`
`obvious claim 10. ..................................................................................................... 22
`Conclusion ................................................................................................ 23
`
`
`
`
`- i -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`
`UPDATED EXHIBIT LIST
`
`Description
`U.S. Patent No. 9,712,502 B2 to Vaarala et al., issued Jul. 18, 2017
`(“the ’502 patent”)
`
`Declaration of David Goldschlag, Ph.D. (“Goldschlag Decl.”)
`
`Prosecution History of U.S. Patent No. 9,712,502 B2 (“’502 Patent
`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 (RFC3104), 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
`
`
`
`
`
`

`

`Exhibit No.
`
`1015
`
`1016
`
`1017
`
`1018
`
`1019
`
`1020
`
`1021
`
`1022
`
`1023
`
`1024
`
`1025
`
`1026
`
`1027
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`
`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 Multi-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”)
`
`Myerson, Judith M., “Identifying enterprise network
`vulnerabilities,” International Journal of Network Management 12,
`135-144 (2002) (“Myerson”)
`
`Kohout, Jiri, “Why is Data Encryption Necessary Even in Private
`Networks?” TeskaLabs, available at https://teskalabs.com/blog/
`seacat-encryption (“Kohout”)
`
`
`
`- iii -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`
`
`
`Introduction
`Patent Owner (“MPH”) presents a single argument in support of the
`
`patentability of the ’502 patent’s independent claim: that the prior art does not
`
`teach a “mobile computer,” as recited in claim 1 of the ’502 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-00824
`U.S. Pat. No. 9,712,502
`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, 11. 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, 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) (“Interpretation of descriptive
`
`statements in a patent’s written description is a difficult task, as an inherent tension
`
`
`
`- 2 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`exists as to whether a statement is a clear lexicographic definition or a description
`
`of a 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 ’502 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 ’502 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.
`
`EX2002, 4:35-39; POR, 13. 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 ’502 patent. Id. And, as MPH’s
`
`expert Dr. Rouskas explains, the ’502 patent uses the terms “mobile terminal,”
`
`
`
`- 3 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`“mobile host,” and “mobile computer” to mean the same thing. EX1023, 163:10-
`
`164:15.
`
`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 ’502 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
`
`
`
`- 4 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`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.
`
`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 ’502 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 ’502 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 ’502 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, 13-17; EX2003,
`
`¶77. These passages of the ’502 patent use the terms “mobile terminal” and
`
`“mobile host,” and as discussed above, MPH’s expert Dr. Rouskas explains that
`
`the ’502 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
`
`
`
`- 5 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`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”—
`
`directly contradicting MPH’s proposed construction that requires a “mobile
`
`computer” to maintain a secure connection when moving.
`
`For example, MPH cites to the ’502 patent at 4:61-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, 15 (citing EX2002, 4:61-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 ’502 patent at 4:17-28, 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, 14 (citing EX2002, 4:17-
`
`28 (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,
`
`
`
`- 6 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`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,
`
`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 ’502 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 [(U.S. Patent No. 9,712,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 ’502 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 ’502 patent
`
`specification to support its proposed construction. POR, 13-17; EX2003, ¶77.
`
`Recognizing Dr. Rouskas’s critical failure to consider the ’502 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
`
`
`
`- 7 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`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
`
`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.
`
`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, 18 (“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. MPH does not dispute that the prior art discloses a “secure
`connection,” and therefore this term need not be expressly
`construed.
`There is no dispute that the prior art teaches a “secure connection,” as
`
`recited in the claims. POR, 23 (“Patent Owner does not dispute that the primary
`
`reference involves a secure connection.”). Therefore, the Board need not expressly
`
`construe this term for the purposes of this proceeding.
`
`
`
`- 8 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
` Ground 1: The combination of RFC3104 and Grabelsky renders
`obvious claims 1-9.
`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, 27-54. 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.
`
`1.
`
`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., 32.
`
`RFC3104, 16.
`
`
`
`
`
`- 9 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`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., 21-22, 32-34 (citing EX1002, ¶¶92-94); POR, 30-31
`
`(citing EX2003, ¶105) (“[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 esp[ecially] on business.” EX1025, Merriam-Webster’s Dictionary,
`
`1077; 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
`
`
`
`- 10 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`connected to the public Internet would be a ‘laptop [i.e., “mobile computer”] [that]
`
`gains access to the Internet.’” Pet., 33 (citing EX1002, ¶94). 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. 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., 32-34 (discussing the Roadwarrior’s reversed scenario).
`
`EX1004, 2 (annotated); EX1022, ¶23.
`
`
`
`
`
`- 11 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`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 end-to-end connection.” POR, 31 (emphasis added).
`
`This 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-12.
`
`As discussed in Section II.A, this attempt to import additional requirements into
`
`the term “mobile computer” is improper and inconsistent with the ’502 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, 31-32,
`
`36, 39-40, 47. But MPH misses the point. RFC3104’s laptop “moves” between
`
`networks (e.g., is a “mobile computer”) because it can disconnect from a first
`
`
`
`- 12 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`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
`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 ’502 patent. Rather, the simple fact
`
`
`
`- 13 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`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.
`
`Accordingly, RFC3104 teaches a “mobile computer” within the context of
`
`the ’502 patent claims, consistent with the usage of the term in the ’502 patent
`
`specification.
`
`B.
`
`The combination of RFC3104 and Grabelsky teaches that “the
`computer is configured to send a signaling message to the
`intermediate computer when the computer changes its address
`such that the intermediate computer can know that the address of
`the computer is changed,” as recited in claim 7.
`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., 32 (citing EX1002, ¶92). As discussed above, this is evidenced at least by
`
`RFC3104’s disclosure of a laptop in the “Roadwarrior” scenario, which all parties
`
`
`
`- 14 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`agree would be expected to move between networks and physical locations. Pet.,
`
`21-22, 32-34 (citing EX1002, ¶¶92-94); POR, 30-31 (citing EX2003, ¶105) (“[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) . . . .”).
`
`Thus, MPH’s arguments that hosts X and Y cannot change address during an
`
`RSIP session are immaterial because this is not a requirement of the claims. Claim
`
`7 merely requires a “signaling message” to be sent “to the intermediate computer
`
`when the computer changes its address.” EX1022, ¶¶31-32. For example, MPH’s
`
`expert Dr. Borella explains that in the context of RFC3104, it is “possible for RSIP
`
`Client X to connect to RSIP Server N with one address, then at some later point
`
`connect to RSIP Server N using a different address.” EX1024, 243:8-21. In this
`
`case, for the moving computer (i.e., “mobile computer”) to reestablish its secure
`
`connection with its peer, an “ASSIGN_REQUEST_RSIPSEC” message would be
`
`sent to RSIP server N to create a binding for the secure connection. Pet., 52-53;
`
`EX1022, ¶32.
`
`MPH’s remaining dispute appears to center on whether the
`
`“ASSIGN_REQUEST_RSIPSEC” message in RFC3104 is used to “signal address
`
`changes of Host X or Host Y.” POR, 56. In particular, MPH’s expert alleges that
`
`“the address field parameters in the ASSIGN_REQUEST_RSIPSEC message are
`
`
`
`- 15 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`used to communicate address information about Server N and message recipient Y,
`
`not information on the address of Host X.” EX2003, ¶145 (emphasis added).
`
`In other words, MPH argues that the ASSIGN_REQUEST_RSIPSEC
`
`message itself does not include the new address of the computer that moved.
`
`EX1022, ¶34. However, this misses the point. MPH concedes that, at a minimum,
`
`the IP packet containing the ASSIGN_REQUEST_RSIPSEC message does
`
`include the address of host X, the moving host. Specifically, Dr. Borella, co-author
`
`of RFC3104, concedes this point:
`
`Q. But the ASSIGN_REQUEST_RSIPSEC message is included in an
`IP packet, right?
`A. Yes.
`Q. And that IP packet would, in fact, provide the address Xa [of]
`RSIP host X, right?
`A. Yes.
`
`EX1024, 247:11-248:1.
`
`Further, neither of the parties dispute that RSIP server N needs to obtain the
`
`address of RSIP client X as part of establishing an RSIP session. EX1022, ¶35. For
`
`example, MPH’s expert Dr. Rouskas explained that the binding created as a result
`
`of the ASSIGN_REQUEST_RSIPSEC message would include the new IP address
`
`of the “mobile” RSIP client, though Dr. Rouskas did not explain how that IP
`
`address is obtained. EX1023, 107:11-15. MPH’s other expert, Dr. Borella, also
`
`
`
`- 16 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`plead ignorance regarding where RSIP server N obtains the new IP address of
`
`RSIP client X. EX1024, 247:17-248:1 (“Q. And you don’t have an opinion on
`
`whether or not that address provided in the source address of the
`
`ASSIGN_REQUEST_RSIPSEC message is what Server N uses to determine the
`
`address of Host X, right? A. Again, that is an implementation detail and I haven’t
`
`formed an opinion of that.”) (emphasis added).
`
`But, as Apple’s expert explains, given that address of host X has to be
`
`obtained from somewhere, the most logical place to obtain that address is from the
`
`IP packet containing the ASSIGN_REQUEST_RSIPSEC message. EX1022, ¶35.
`
`Indeed, as explained above, Dr. Borella explains that this is possible and would
`
`simply be an “implementation detail.” EX1024, 241:6-12. Then, following receipt
`
`of the new ASSIGN_REQUEST_RSIPSEC message, the Petition explains that
`
`“the RSIP server N can create a mapping of the assigned parameters to the address
`
`of the RSIP client.” Pet., 52. Therefore, this IP packet containing the
`
`ASSIGN_REQUEST_RSIPSEC message acts as “a signaling message [sent] to
`
`the intermediate computer when the computer changes its address such that the
`
`intermediate computer can know that the address of the computer is changed,” as
`
`required by claim 7. Id., 51-53.
`
`
`
`- 17 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`C. The combination of RFC3104 and Grabelsky teaches that “the
`computer is configured to send the signaling message encrypted,”
`as recited in claim 8.
`As explained in the Petition, “a POSITA would have been motivated to
`
`ensure that every transmission is secured either by authentication or encryption.”
`
`Pet., 53-54; EX1002, ¶134. MPH argues three points with respect to this claim.
`
`These arguments overstate the complexity of encrypting messages, which was well
`
`known and ubiquitous in computer networking at the time of the ’502 patent.
`
`EX1022, ¶36.
`
`First, MPH alleges that “because ‘the ARR
`
`(ASSIGN_REQUEST_RSIPSEC)] message would be sent from X at Xa to Na at
`
`Server N within a private network space,’ a POSITA would see ‘no need to encrypt
`
`the message’ and would understand that doing so would introduce ‘unnecessary
`
`complexity and processing overhead.’” POR, 58 (citing EX2003, ¶149). But
`
`RFC3104’s use of “a private address space” in its discussion is merely provided as
`
`an example. RSIP does not require or even expect address space A to always refer
`
`to a private address space: “For example, A could be a private address space, and
`
`B the public address space of the general Internet.” EX1004, 3; EX1022, ¶37.
`
`Indeed, RFC3104 provides the example “Roadwarrior scenario” in which the RSIP
`
`client X connects to RSIP server N over the “public Internet.” EX1004, 16;
`
`EX1022, ¶37. Additionally, as Dr. Goldschlag explains, private networks are also
`
`
`
`- 18 -
`
`

`

`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`subject to attack, and thus message encryption produces higher security. EX1022,
`
`¶38.
`
`Second, MPH alleges that “the ‘ARR message is simply a signal used to
`
`“request IPSec parameter assignments”’ (quoting Ex. 1