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
`____________________
`
`DECLARATION OF DAVID GOLDSCHLAG, PH.D., IN SUPPORT OF
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`EX1022
`Apple v. MPH
`IPR2019-00824
`
`
`
`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
`____________________
`
`DECLARATION OF DAVID GOLDSCHLAG, PH.D., IN SUPPORT OF
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`EX1022
`Apple v. MPH
`IPR2019-00824
`
`
`
`TABLE OF CONTENTS
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`
`Introduction ...................................................................................................... 1
`Dr. Rouskas’s proposed construction of “mobile computer” does not
`comport with the ’502 patent specification. .................................................... 2
` RFC3104 discloses a “mobile computer,” as recited in claim 1. .................... 8
`A. RFC3104 teaches the use of a mobile computer, e.g., a laptop, that moves
`physical locations and changes networks. .................................................. 8
`B. The opinions of Dr. Rouskas and Dr. Borella regarding whether a laptop
`can change addresses during the course of an RSIP-IPSec session are
`irrelevant. .................................................................................................. 12
` 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. ... 15
`The combination of RFC3104 and Grabelsky teaches that “the computer is
`configured to send the signaling message encrypted,” as recited in claim 8.
` ....................................................................................................................... 18
` Claims 2-6, 9, and 10 are obvious for the reasons set forth in my original
`declaration. ..................................................................................................... 24
` Conclusion ..................................................................................................... 25
`
`i
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`
`I, David Goldschlag, Ph.D., hereby declare as follows:
`
`
`
`Introduction
`1.
`I am the same David Goldschlag, Ph.D. who submitted a prior
`
`declaration (EX1002) in this matter, which I understand was filed on March 29,
`
`2019. I have been retained on behalf of Apple Inc. (“Petitioner”) for the above-
`
`captioned inter partes review proceeding.
`
`2. My background and qualifications were provided in paragraphs 11-20
`
`of my prior declaration, and my CV was provided as EX1021. My statements in
`
`paragraphs 2-5 of my prior declaration regarding my review of U.S. Patent No.
`
`9,712,502 (“the ’502 patent”) and related materials remain unchanged, as do my
`
`understandings of the relevant legal principles stated in paragraphs 21-33.
`
`3.
`
`Since my prior declaration, I have reviewed and considered the
`
`following additional materials:
`
`Paper
`
`Description
`
`7
`
`Decision Granting Institution, IPR2019-00824 (“DI”)
`
`13
`
`Exhibit
`1023
`
`1024
`
`
`
`Patent Owner’s Response
`
`Description
`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.”)
`
`1
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`
`Exhibit
`1025
`
`1026
`
`1027
`
`2003
`
`2010
`
`Description
`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”)
`Declaration of Professor George N. Rouskas, Ph.D
`
`Declaration of Michael S. Borella
`
`4.
`
`I have also considered all other materials cited herein, which are true
`
`and accurate copies of what they purport to be, to the best of my knowledge. My
`
`work on this case is being billed at my normal hourly rate, with reimbursement for
`
`actual expenses. My compensation is not contingent upon the outcome of this inter
`
`partes review proceeding.
`
`5.
`
`I understand that Patent Owner MPH Technologies Oy (“Patent
`
`Owner”) submitted declarations from two individuals to support the arguments in
`
`its Patent Owner’s Response: Dr. George N. Rouskas and Dr. Michael S. Borella. I
`
`address the testimony of both individuals throughout this declaration.
`
` Dr. Rouskas’s proposed construction of “mobile computer” does not
`comport with the ’502 patent specification.
`6.
`Dr. Rouskas contends that the term “mobile computer” should be
`
`construed as “a computer that moves from one network to another as opposed to a
`
`
`
`2
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`computer that is only capable of a static secure connection.” EX2003, ¶72. In my
`
`opinion, this construction is very similar to Patent Owner’s proposed construction
`
`in its Preliminary Response, which proposed construing this term “to require a
`
`computer that is capable of moving from one network to another while maintaining
`
`a connection.” POPR, 4. I understand that the Board rejected this construction in
`
`its Institution Decision. See DI, 11. Dr. Rouskas’s proposed construction here is
`
`incorrect for similar reasons.
`
`7.
`
`Dr. Rouskas cites to a number of passages in the ’502 patent to
`
`support his proposed construction. EX2003, ¶¶76-78. Dr. Rouskas 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; EX2003, ¶76.
`
`8.
`
`This language is extremely broad. This passage states that the terms
`
`“mobility” and “mobile terminal” “not only mean physical mobility,” but also can
`
`mean a terminal (e.g., computer) that “move[s] from one network to another.” Id.
`
`The ’502 patent does not define the terms “mobility” and “mobile terminal”
`
`elsewhere in the ’502 patent. I also understand that Dr. Rouskas opines the ’502
`
`patent uses the terms “mobile terminal,” “mobile host,” and “mobile computer” to
`3
`
`
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`mean the same thing. EX1023, Rouskas Dep., 163:10-164:15. I agree that these
`
`terms are generally used interchangeably throughout the ’502 patent.
`
`9.
`
`This explanation of “mobility” and “mobile terminal” is consistent, if
`
`not broader, than the ordinary meaning term “mobile” as used in the art. For
`
`example, Merriam-Webster defines “mobile” as “capable of moving or being
`
`moved : MOVABLE.” EX1025, Merriam-Webster’s Dictionary, 797. The
`
`explanation of “mobility” and “mobile terminal” in the ’502 patent encompasses
`
`this ordinary meaning of the term “mobile,” as well as includes computers capable
`
`of moving between networks even if they are physically fixed. Thus, to the extent
`
`“mobile computer” requires express construction in this proceeding, the term
`
`should be construed as “a computer that is capable of moving between networks or
`
`physical locations.”
`
`10.
`
`I understand that Dr. Rouskas 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.
`
`
`
`4
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`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.
`11. Thus, even Dr. Rouskas agreed that on their own, the use of the terms
`
`“mobility” and “mobile terminal” in the ’502 patent do not suggest anything more
`
`than moving networks and/or physical location. Dr. Rouskas further opined that he
`
`did not form an opinion of 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. The ’502
`
`patent is not specific on this point, and so in my opinion, a POSITA would have
`
`understood that the claims require at least the capability of moving between
`
`networks or physical locations.
`
`12.
`
`I also understand that Patent Owner relied on the testimony of
`
`Michael Borella, the first-named author of RFC3104. See generally EX2010. I
`
`further understand that 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
`5
`
`
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`Dep., 230:17-20. Thus, there appears to be no disagreement among Dr. Rouskas,
`
`and Dr. Borella, and myself, that the term “mobile computer” simply means
`
`moving (or the capability of moving) between networks or physical locations.
`
`13. The portion of Dr. Rouskas’s proposed construction that attempts to
`
`differentiate the term “mobile computer” from “a computer that is only capable of
`
`a static secure connection” is unsupported by the ’502 patent. Dr. Rouskas cites to
`
`other passages of the ’502 patent to support this portion of his proposed
`
`construction of “mobile computer,” but these passages use the terms “mobile host”
`
`and “mobile terminal” to refer to computers establishing a “static secure
`
`connection.” See EX2003, ¶77 (citing EX2002, 4:17-28, 4:61-64). As I discuss
`
`above, the ’502 patent uses the terms “mobile terminal,” “mobile host,” and
`
`“mobile computer” to mean the same thing, as Dr. Rouskas explained. EX1023,
`
`163:10-164:15.
`
`14. For example, Dr. Rouskas 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.” EX2003, ¶77 (citing EX2002,
`
`4:61-64) (emphasis added)). 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. In other words, this passage explains that because
`
`
`
`6
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`the IPSec connections established by the “mobile terminal” are bound to fixed
`
`addresses, the mobile terminal must disconnect its connection when moving and
`
`reconnect when joining a new network.
`
`15. Dr. Rouskas further cites 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.” EX2003,
`
`¶77 (citing EX2002, 4:17-28) (emphasis in original). Again, this passage plainly
`
`uses the term “mobile host” in conjunction with a computer reestablishing static
`
`IPSec connections when moving rather than maintaining them. Indeed, Dr.
`
`Rouskas himself emphasized the bolded portion of this citation, yet he ignored that
`
`the cited “mobile host” would not meet his proposed construction of “mobile
`
`computer.” Thus, these passages show that Dr. Rouskas’s proposed construction of
`
`“mobile computer” is inconsistent with the use of the term throughout the ’502
`
`patent specification, which is used merely to refer to computers that move or
`
`would be expected to move in some manner.
`
`16. For these reasons, it is my opinion that Dr. Rouskas’s proposed
`
`construction of “mobile computer” is overly-narrow, requiring such a computer to
`
`maintain its secure connection any time it moves, which is inconsistent with the
`
`
`
`7
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`use of “mobile computer,” “mobile host,” and “mobile terminal” throughout the
`
`’502 patent specification.
`
` RFC3104 discloses a “mobile computer,” as recited in claim 1.
`17. Dr. Rouskas’s argument for the patentability of claim 1 appears to be
`
`premised on his incorrect construction of the term “mobile computer.” EX2003,
`
`¶¶100-139. As I discuss below and in my original declaration, the combination of
`
`RFC3104 and Grabelsky teaches a “mobile computer” based on the term’s
`
`ordinary meaning and the ’502 patent specification.
`
`A. RFC3104 teaches the use of a mobile computer, e.g., a laptop, that
`moves physical locations and changes networks.
`18. As I discuss in my original declaration, 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); EX1002, ¶¶92-94.
`
`
`
`RFC3104, 16.
`
`8
`
`
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`In this scenario, I explain in my original declaration that “[b]ecause
`
`19.
`
`the user with the laptop is on the road, a POSITA would have understood that the
`
`laptop would change its point of attachment and its address when connecting to the
`
`Internet from different locations,” and is thus a “mobile computer.” EX1002, ¶94.
`
`Dr. Rouskas also agrees that a POSITA would have understood that the laptop
`
`moves from one network to another, and is thus a “mobile computer.” EX2003,
`
`¶105 (“A POSITA would understand that a businessperson on the road with a
`
`laptop can be expected to connect to different networks and have different fixed IP
`
`addresses at different points in time. A POSITA would understand that as a
`
`computer changes networks it will change IP addresses.”). This is consistent with
`
`the ordinary meaning of the term “road warrior,” i.e., “a person who travels
`
`frequently esp[ecially] on business,” as a POSITA would have understood the term
`
`reading RFC3104 at the time of the ’502 patent. EX1025, 1077.
`
`20. Further, I understand that during cross-examination, 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). I
`
`further understand that Patent Owner’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
`
`
`
`9
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`“mobile computer.” EX1024, 218:7-219:3. Thus, all experts agree that the laptop
`
`used in RFC3104’s Roadwarrior scenario is “mobile” in that it moves from one
`
`network to another.
`
`21. With this understanding of a “mobile computer” in the context of
`
`RFC3104’s Roadwarrior scenario, I explained in my original declaration 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.’” EX1002, ¶94. I understand that Dr.
`
`Borella, a co-author of RFC3104, also agreed that the “Roadwarrior scenario” can
`
`be reversed, meaning that “Host Y can initiate the connection instead of Host X.”
`
`EX1024, 248:9-14; EX1004, 16. This testimony makes Dr. Borella’s distinctions
`
`with regard to which host in the Roadwarrior scenario is an RSIP client (see
`
`EX2010, ¶60) irrelevant.
`
`22.
`
`In particular, Dr. Borella attempted to distinguish RFC3104’s
`
`Roadwarrior scenario from RFC3104’s “core” diagram, stating that “[a] POSITA
`
`would have observed and understood that the more relevant distinction between
`
`hosts X and Y is which one has the role of being the RSIP client.” EX2010, ¶60.
`
`However, since the Roadwarrior scenario explicitly contemplates both scenarios in
`
`which either host X or host Y plays the role of the RSIP client, as conceded by Dr.
`
`Borella, there is no substantial difference between the operation of hosts X and Y
`
`
`
`10
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`and RSIP server N in RFC’s “core” diagram and the Roadwarrior scenario. The
`
`Roadwarrior scenario simply provides a particular scenario in which one of the
`
`hosts is specified to be a laptop.
`
`23. The “reverse” scenario, in particular, aligns well 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.
`
`EX1004, 2 (annotated).
`
`
`
`24. Dr. Rouskas further attempts to attack the Roadwarrior scenario by
`
`stating that “the Roadwarrior connection is premised on ‘mechanisms not disclosed
`
`in this document.’” EX2003, ¶130. But this misinterprets the Roadwarrior
`
`scenario, as well as the purpose for which the Roadwarrior scenario is relied upon.
`
`This statement in RFC3104 merely relates to a proposed “authentication and
`
`authorization phase” of RSIP prior to establishing an RSIP session. The next
`
`sentence states, “[a]fter that phase is completed, the IPsec extensions to RSIP
`
`
`
`11
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`defined here are used to establish an IPsec session with a peer.” EX1004, ¶16
`
`(emphasis added). That is, the Roadwarrior scenario relies on the same
`
`mechanisms as the “core” implementation discussed in the main part of RFC3104
`
`(i.e., pages 2-10), which none of the experts dispute could have been implemented
`
`by a POSITA. Indeed, Dr. Borella stated that he was aware of actual
`
`implementations of RSIP. EX1024, 137:16-18. Again, the Roadwarrior scenario
`
`merely provides a particular scenario in which the concepts described in the main
`
`document can be applied.
`
`25. Thus, for the reasons above and in my original declaration, RFC3104
`
`plainly contemplates the use a “mobile” laptop involved in a secure RSIP
`
`connection, as illustrated by RFC3104’s “Roadwarrior scenario.”
`
`B.
`
`The opinions of Dr. Rouskas and Dr. Borella regarding whether a
`laptop can change addresses during the course of an RSIP-IPSec
`session are irrelevant.
`26. The only actual dispute presented by either of Patent Owner’s experts
`
`is that “a POSITA would not view the Roadwarrior scenario . . . as disclosing that
`
`Host X is moving from an IP address in one network to an IP address in another
`
`network during the RSIP connection to Server N that extends to the end-to-end
`
`communication with Host Y.” EX2003, ¶105 (emphasis added). This statement,
`
`and the rest of Dr. Rouskas’s analysis, illustrate that Dr. Rouskas’s argument
`
`amounts to an assertion that the claimed “mobile computer” must be able to move
`
`
`
`12
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`networks while maintaining its connection, the same argument that I understand
`
`Patent Owner put forth in its Patent Owner Preliminary Response and was
`
`previously considered and rejected by the Board. See DI, 9-11. As I discussed in
`
`Section II above, this argument and Dr. Rouskas’s understanding is inconsistent
`
`with the ’502 patent’s usage of the term “mobile computer.”
`
`27. Dr. Borella further alleges that “a POSITA would have understood
`
`that if host X or host Y changes its address, the IPSEC session between them
`
`would be rendered inoperable.” EX2010, ¶63. But this misses the point, and this is
`
`not a flaw in RSIP that would render it “inoperable” by any means. Of importance
`
`is that 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, neither Dr. Borella nor Dr. Rouskas
`
`appear to dispute that operation.
`
`28. Specifically, I understand that 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?
`
`
`
`13
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`
`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 (Patent
`
`Owner’s expert Dr. Rouskas testifying that such a scenario is contemplated by
`
`RFC3104).
`
`29.
`
`In other words, Dr. Borella admitted in 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 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:9-225:4. I agree with Dr. Borella in this respect, as I have discussed
`
`in detail above. 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 appears to be contrary to
`
`his testimony on cross-examination. See EX2010, ¶¶44-63.
`
`
`
`14
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`30. Therefore, 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, as I discuss above.
`
` 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.
`31. As I explained in my original declaration, 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.”
`
`EX1002, ¶92 (emphasis added). As I discussed above, this is evidenced at least by
`
`RFC3104’s disclosure of a laptop in the “Roadwarrior” scenario, which I
`
`understand that all parties agree would be expected to move between networks and
`
`physical locations. 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 and have different fixed IP addresses at
`
`different points in time. A POSITA would understand that as a computer changes
`
`networks it will change IP addresses.”)).
`
`32. Thus, Dr. Rouskas’s arguments that hosts X and Y cannot change
`
`address during an RSIP session are immaterial because this is not a requirement of
`
`
`
`15
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`the claims, as discussed above. Claim 7 merely requires a “signaling message” to
`
`be sent “to the intermediate computer when the [mobile] computer changes its
`
`address,” not that the “mobile computer” maintain any active connection while it
`
`moves. And Patent Owner’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:15-21. In this case, for the moving computer (i.e.,
`
`“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. See EX1002, ¶¶131-33.
`
`33. Dr. Rouskas’s and Patent Owner’s remaining dispute appears to relate
`
`to whether the “ASSIGN_REQUEST_RSIPSEC” message in RFC3104 is used to
`
`“signal address changes of Host X or Host Y.” EX2003, ¶145. Specifically, Dr.
`
`Rouskas alleges that “the address field parameters in the
`
`ASSIGN_REQUEST_RSIPSEC message are used to communicate address
`
`information about Server N and message recipient Y, not information on the
`
`address of Host X.” Id., ¶145 (emphasis added).
`
`34.
`
`In other words, Dr. Rouskas alleges that the
`
`ASSIGN_REQUEST_RSIPSEC message itself does not include the new address
`
`of the computer that moved. However, this is essentially a distinction without a
`
`
`
`16
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`difference. Patent Owner’s other expert, Dr. Borella, 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, who I
`
`again note is a co-author of RFC3104, testified:
`
`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:22-16.
`
`35. Additionally, 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. For
`
`example, I understand that 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 I understand that Dr. Rouskas did not
`
`explain how that IP address is obtained. EX1023, 107:11-15. And 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. Otherwise, a separate message would
`
`need to be sent, which is inefficient and a POSITA would have expected would
`
`
`
`17
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`increase overhead during creation of the RSIP binding. Indeed, Dr. Borella
`
`explains that this is possible and would merely be an “implementation detail.”
`
`EX1024, 247:17-248:1. Then, following receipt of the new
`
`ASSIGN_REQUEST_RSIPSEC message, “the RSIP server N can create a
`
`mapping of the assigned parameters, as described in RFC3102, to the address of
`
`the RSIP client.” EX1002, ¶132. 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., ¶¶132-33.
`
` The combination of RFC3104 and Grabelsky teaches that “the
`computer is configured to send the signaling message encrypted,” as
`recited in claim 8.
`36. As I explained in my original declaration, “a POSITA would have
`
`been motivated to employ encryption at least to secure requested and assigned
`
`parameters prior to an end-to-end SA being established. A POSITA would have
`
`been motivated to do so because exposing parameters used in the IPSec SA
`
`increases the vulnerability of the connection.” EX1002, ¶134. Dr. Rouskas argues
`
`four 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, as discussed further below.
`
`
`
`18
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`
`37. First, Dr. Rouskas alleges that “the ARR
`
`[(ASSIGN_REQUEST_RSIPSEC)] message would be sent from X at Xa to Na at
`
`Server N within a private network space,” and “[t]here would be no need to
`
`encrypt this message when it is sent within a private network space.” 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
`
`(emphasis added). Significantly, RFC3104 further provides the example
`
`“Roadwarrior scenario” in which the RSIP client X connects to RSIP server N over
`
`the “public Internet.” EX1004, 16 (emphasis added). Dr. Rouskas does not appear
`
`to consider this scenario as part of his arguments.
`
`38. Additionally, private networks are also subject to attack, and thus
`
`message encryption produces higher security. Indeed, this is why such extreme
`
`measures are taken to protect corporate networks, often encrypting messages even
`
`inside the private network, which was important at the time of the ’502 patent just
`
`
`
`19
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`as it is now.1 Thus, a POSITA would have been motivated to encrypt potentially-
`
`sensitive information, using well-known encryption techniques, even within a
`
`private network.
`
`39. Second, Dr. Rouskas alleges that “there is nothing in RFCs 3104,
`
`3102 or 3103 that remotely suggests that the ARR message or any of the other
`
`RSIP messages are encrypted or could or should be encrypted.” EX2003, ¶150.
`
`Again, this misses the point. The reasoning in my original declaration did not rely
`
`on explicit disclosures from the RSIP RFCs, but rather what a POSITA would have
`
`recognized and been motivated to implement. EX1002, ¶¶134-36.
`
`40. Third, Dr. Rouskas alleges that “[t]he ARR message is simply a signal
`
`used to ‘request IPSec parameter assignments,’” and “does not expose IPSec SA
`
`parameters.” EX2003, ¶151 (citing EX1004, 7). This is incorrect. This argument
`
`ignores that the parameters requested in the ASSIGN_REQUEST_RSIPSEC often
`
`do become the assigned parameters of the RSIP connection. In particular,
`
`RFC3104 provides both an ASSIGN_REQUEST_RSIPSEC message and an
`
`ASSIGN_RESPONSE_RSIPSEC message. The latter “is used by an RSIP server
`
`
`1 See, e.g., EX1027, Kohout; EX1026, Myerson, 1, 3 (“Examples of
`
`safeguards [in an enterprise network] include biometric controls, use of encryption,
`
`awareness programs, audit trails and visitor controls.”) (emphasis added).
`
`
`
`20
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`to assign parameters to an IPsec-enabled RSIP client.” EX1004, 8. These messages
`
`contain many of the same fields, as shown in the formats below:
`
`EX1004, 8-9.
`
`
`
`41. For example, RFC3104 explains that the “SPI” field is “[s]ent by the
`
`RSIP client in ASSIGN_REQUEST_RSIPSEC messages to ask for a particular
`
`number of SPIs to be assigned,” which can include actual SPI values to be assigned
`
`for use with the RSIP connection and IPSec Security Association (SA). Id., 9; see
`
`also id., 8 (if “the RSIP server cannot allocate it because the requested address and
`
`SPI tuple is in use, the RSIP server MUST respond with an ERROR_RESPONSE
`
`containing the IPSEC_SPI_INUSE error.” (emphasis added)). The SPI field is an
`
`example of an “IPSec SA parameter,” which would be exposed in both the
`
`ASSIGN_REQUEST_RSIPSEC and ASSIGN_RESPONSE_RSIPSEC messages.
`
`RSIP clients can also request other parameters that RSIP server N can assign to the
`
`created RSIP connection, such as addresses, ports, lease time, and others, as shown
`
`
`
`21
`
`
`
`Case IPR2019-00824
`U.S. Pat. No. 9,712,502
`above. EX1004, 7-10. Thus, Patent Owner’s allegation that the
`
`ASSIGN_REQUEST_RSIPSEC message does not expose parameters is incorrect.
`
`42. Finally, Dr. Rouskas alleges that because the
`
`ASSIGN_REQUEST_RSIPSEC message is a “pre
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
