`
`Patent 9,712,494
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`
`Petitioner,
`
`V.
`
`NEPH TECHNOLOGIES OY,
`Patent Owner.
`
`Case IPR2019—00823
`
`Patent 9,712,494
`
`EXHIBIT 2010
`
`DECLARATION OF MICHAEL S. BORELLA
`
`Exhibit 2010
`Page 2010-1
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`TABLE OF CONTENTS
`
`Page
`
`INTRODUCTION ....................................................................................... 1
`
`QUALIFICATIONS .................................................................................... 2
`
`III.
`
`BASES OF OPINIONS ............................................................................... 4
`
`IV.
`
`ORDINARY SKILL IN THE ART ........................................................... 4
`
`NETWORK ADDRESS TRANSLATION ................................................ 6
`
`VI.
`
`REALM SPECIFIC IP (RSIP) ................................................................... 7
`
`VII. RSIP WITH IPSEC ..................................................................................... 9
`
`VIII. CLAIM CONSTRUCTION ...................................................................... 14
`
`IX.
`
`A POSITA WOULD HAVE CONCLUDED THAT THE RSIP
`
`FRAMEWORK OF RFC 3104 DOES NOT TEACH OR SUGGEST
`
`HOST MOBILITY AS DEFINED IN THE ’494 PATENT .................. 15
`
`A.
`
`The ’494 Patent Addresses the Deficiencies of IPSEC in the
`
`Presence of Host Mobility .................................................................. 15
`
`B.
`
`RFC 3104 is Silent Regarding Host Mobility .................................... 16
`
`C.
`
`RFC 3104 Does Not Teach a POSITA That Host X or Host Y of
`
`the RSIP Model Changes Addresses as Described by Dr.
`Goldschlag .......................................................................................... 17
`
`D.
`
`RFC 3104 Does Not Teach a POSITA That Host X or Host Y of
`
`the Roadwarrior Scenario Changes Addresses as Described by Dr.
`Goldschlag .......................................................................................... 19
`
`E.
`
`A POSITA Would Have Understood That the
`
`ASSIGN_REQUEST_IPSEC Message is Not Used to Provide an
`Address of Address space A to Host X .............................................. 23
`
`Exhibit 2010
`Page 2010-2
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`A POSITA WOULD HAVE UNDERSTOOD THAT RFC
`
`DOCUMENTS ARE INTENDED TO BE READ IN COMBINATION
`
`WITH ONE ANOTHER ........................................................................... 26
`
`CONCLUSION .......................................................................................... 27
`
`Exhibit 2010
`Page 2010-3
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`INTRODUCTION
`
`1.
`
`My name is Michael S. Borella. I have been retained as an expert
`
`witness to provide my independent opinion regarding matters at issue in the inter
`
`partes review of US. 9,712,494 (“the ’494 Patent”) in the IPR2019-00823
`
`proceeding. I have been retained by MPH Technologies Oy (“MPH”), the Patent
`
`Owner, in the above proceedings. Petitioner in this case is Apple Inc. (“Apple”).
`
`2.
`
`Unless otherwise noted, the statements made herein are based on my
`
`personal knowledge, and if called to testify about this declaration, I could and
`
`would do so competently and truthfiJlly.
`
`3.
`
`A detailed record of my professional qualifications can be found in
`
`Exhibit 2009 and is summarized in Section II, infia.
`
`4.
`
`In addition to being a technical expert, I am a practicing patent
`
`attorney. In this proceeding, however, I am serving as a fact witness and a
`
`technical expert witness, not submitting testimony as an expert on the law.
`
`5.
`
`All statements in this declaration are in my opinion, and to the best of
`
`my knowledge and understanding. Some of these Opinions are based, in part, on
`
`my recollection of events surrounding the development of technologies at issue in
`
`this proceeding. All statements regarding the understanding of one of ordinary
`
`skill in the art have been made to reflect that understanding at the time of invention
`
`of the ’494 Patent.
`
`Exhibit 2010
`Page 2010-4
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`6.
`
`I wish to disclose that I am a co-author of RFC 3104 (Ex. 1004) and
`
`RFC 3102 (Ex. 1019). See Ex. 1004, 1 (“M. Borella”); Ex. 1019, 1 (“M. Borella”).
`
`The Petitioner in this case relies on RFC 3104 as the primary reference in both of
`
`its grounds.
`
`QUALIFICATIONS
`
`7.
`
`I am an experienced researcher, educator, software engineer, manager,
`
`and executive, serving in a variety of roles in industry and academia. My areas of
`
`technical expertise include computer networking, telecommunications, Internet
`
`protocols, network security, operating systems, wireless networks, and mobile
`
`applications.
`
`8.
`
`I have over twenty—eight years of experience in computer networking
`
`since I received by bachelor’s degree in computer science in 1991. I have twelve
`
`years of industry software and networking experience at 3Com Corporation,
`
`Commworks (a subsidiary of 3Com Corporation), UTStarcom, and Fastmobile
`
`since receiving my Ph.D. in computer science in 1995. This time period overlaps
`
`in part with my ten years as a professor / instructor at Northwestern University and
`
`DePaul University in electrical engineering and computer science, reSpectively. In
`
`2007, I became a technical advisor with McDonnell Boehnen Hulbert and
`
`Berghoff, LLP (MBHB) focused on advising entities of various sizes in regard to
`
`computer networking, telecommunications, Internet protocols, network security,
`
`Exhibit 2010
`Page 2010-5
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`operating systems, wireless networks, mobile applications, and cloud computing.
`
`Further details are contained in my CV. provided as Exhibit 2009.
`
`9.
`
`During this time, I have led, overseen, and contributed to numerous
`
`research and commercial projects involving concepts that are related to the
`
`technology at issue in the IPR2019-00823 proceeding. Most notably, I am co-
`
`author of Internet Engineering Task Force (IETF) RFCs 3102, 3103, and 3104 (Ex.
`
`1019, 2004, and 1004, respectively, of this proceeding). RFCs 3102 and 3104
`
`have been cited by Petitioner as alleged prior art in this proceeding. I understand
`
`that Petitioner’s two grounds in this IPR are based on RFC 3104 as the primary
`
`reference.
`
`10.
`
`In addition to these works, I have co-authored over 30 technical
`
`research papers in the area of networked communications and am a named inventor
`
`on numerous US. and foreign patents in that area. According to a search of
`
`Google Scholar conducted on February 6, 2020, my research papers, patents,
`
`patent applications, and contributions to standards bodies such as the IETF have
`
`been cited by others over 10,000 times.
`
`11.
`
`I received a Ph.D. in computer science from the University of
`
`California, Davis in 1995, an MS. in computer science from the same university in
`
`1994, and a BS. in computer science and technical communications (with
`
`distinction) from Clarkson University in 1991.
`
`Exhibit 2010
`Page 2010-6
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`12. My academic work includes two years as tenure-track faculty in the
`
`computer science department of DePaul University, as well as eight years as an
`
`adjunct professor in the electrical engineering department of Northwestern
`
`University.
`
`BASES OF OPINIONS
`
`13.
`
`In the course of conducting my analysis and forming my opinions in
`
`light of my own knowledge and experience, I have reviewed at least the
`
`information mentioned herein.
`
`ORDINARY SKILL IN THE ART
`
`14. My opinions in this declaration are based on the understandings of a
`
`person of ordinary skill in the art, which is sometimes referred to by the acronyms
`
`“POSITA” (person of ordinary skill in the art) or “PHOSITA” (person having
`
`ordinary skill in the art), as of the time of the invention. In this case, I understand
`
`the time of the invention to be at least as early as January 21, 2003, which is the
`
`filing date of the PCT Patent Application No. PCT/F12003/000045 from which
`
`priority was asserted by original US Patent Application No. 10/500,930. US.
`
`US. Patent Application No 10/500,930 issued as US. Patent No. 8,346,949, and
`
`priority from which was asserted by the present application through an intervening
`
`application. I also understand that the priority chain of the present application
`
`extends from the above mentioned PCT Application to the January 22, 2002, filing
`
`Exhibit 2010
`Page 2010-7
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`date of the application filed in Finland, FI 2002/0112. See EX. 1001 (Cover Page).
`
`My analysis and conclusions are the same whether the relevant time period is 2003
`
`or 2002. I understand that the POSITA is a hypothetical person who is presumed
`
`to have known the relevant art at the time of the invention. By “relevant,” I mean
`
`relevant to the challenged claims of the ’494 Patent.
`
`15.
`
`I understand that, in assessing the level of skill of a POSITA, one
`
`should consider the type of problems encountered in the art, the prior solutions to
`
`those problems found in the prior art references, the rapidity with which
`
`innovations are made, the sophistication of the technology, and the level of
`
`education of active workers in the field.
`
`16.
`
`In this case, Dr. Goldschlag has asserted in his declaration that a
`
`POSITA at the time of the ’494 Patent would have had a bachelor’s degree in
`
`electrical engineering, computer engineering, computer science, or an equivalent
`
`field as well as at least 2-5 years of academic or industry experience in the field of
`
`Internet security. EX. 1002, 1] 31. In my view, this is a reasonable standard for the
`
`level of ordinary skill in the art for the present matter.
`
`17.
`
`I was at the time of invention, and am, more than one of ordinary skill
`
`in the art through my education and research experience. As of the date of the
`
`invention, I was very familiar with the types of problems encountered in computer
`
`network security, the types of solutions described in prior art references, the
`
`Exhibit 2010
`Page 2010-8
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`rapidity at which innovations were made, had extensive experience working with
`
`those of ordinary skill in the art. Thus, I am qualified to opine upon the knowledge
`
`of a POSITA at the time of the invention.
`
`NETWORK ADDRESS TRANSLATION
`
`18. Network address translation (NAT) is a mechanism through which a
`
`NAT—enabled router connecting two addressing domains (or realms) can “examine
`
`and change the network layer, and possibly the transport layer, header of each
`
`packet crossing the addressing domains that the NAT router is connecting.”
`
`Exhibit 1019 (RFC 3102), 2. NATs have been used to connect devices on
`
`addressing realms that are otherwise unrouteable to one another — such as a
`
`privately addressed realm (e.g., a home network) and a publicly addressed realm
`
`(e.g., the Internet). This allows communications from hosts within the privately
`
`addressed realm to share one or more public IP addresses of the NAT—enabled
`
`router without any modifications to the hosts, or the hosts having to be aware of
`
`the NAT.
`
`19.
`
`But such modifications to packets “violate the end-to—end nature of
`
`the Internet connectivity, and disrupt[] protocols requiring or enforcing end—to-end
`
`integrity of packets.” Id. A notable example of such a protocol is IPSEC. IPSEC
`
`employs end-to-end encryption and/or authentication of higher layer protocols
`
`(e.g., TCP, UDP, and any application payload encapsulated therein), which makes
`
`Exhibit 2010
`Page 2010-9
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`it impractical or impossible for some IPSEC packets to successfully traverse a
`
`NAT. See, e.g., EX. 2004 (RFC 3103), 3.
`
`REALM SPECIFIC IP (RSIP)
`
`20.
`
`Realm Specific IP (RSIP) relates to an architecture and protocol that
`
`provides an “alternative to NAT in which the end—to—end integrity of packets is
`
`maintained.” Exhibit 1019 (RFC 3102), 1. RSIP was designed with the intention
`
`of being able to “ameliorate some IP address shortage problems in some scenarios
`
`without some of the limitations of NAT.” Id, 3.
`
`21.
`
`RSIP enables “a host from one addressing realm a presence in another
`
`addressing realm by allowing it to use resources (e.g., addresses and other routing
`
`parameters) fiom the second addressing realm.” Id. The host may be referred to as
`
`an RSIP host and the NAT-enabled router may be replaced with an RSIP gateway
`
`(also referred to as “RSIP Server N”) that manages the assignment of these
`
`resources across one or more RSIP hosts. Id., 3—5.
`
`22.
`
`RSIP as defined in RFC 3102 comes in two main variations, RSA-IP
`
`and RSAP-IP. RSA—IP is described as follows:
`
`When using RSA-IP, an RSIP gateway maintains a pool of IP
`
`addresses to be leased by RSIP hosts. Upon host request, the RSIP
`
`gateway allocates an IP address to the host. Once an address is allocated
`
`to a particular host, only that host may use the address until the address
`
`is returned to the pool. Hosts MAY NOT use addresses that have not
`
`Exhibit 2010
`Page 2010-10
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`been specifically assigned to them. The hosts may use any TCP/UDP
`
`port in combination with their assigned address. 1d,, 7.
`
`23.
`
`In contrast, RSAP-IP is described as follows:
`
`When using RSAP-IP, an RSIP gateway maintains a pool of IP
`
`addresses as well as pools ofport numbers per address. RSIP hosts lease
`
`an IP address and one or more ports to use with it. Once an address /
`
`port tuple has been allocated to a particular host, only that host may use
`
`the tuple until it is returned to the pool(s). Hosts MAY NOT use address
`
`/ port combinations that have not been specifically assigned to them.
`
`Id.
`
`24. When using the assigned IP addresses and/or ports, RSIP requires
`
`tunneling between each RSIP host and its RSIP gateway. Id, 6. Notably:
`
`Using the public parameters assigned by the RSIP gateway, RSIP
`
`hosts tunnel data packets across address space A to the RSIP gateway.
`
`The RSIP gateway acts as the end point of such tunnels, stripping off
`
`the outer headers and routing the inner packets onto the public realm. .
`
`.
`
`. When a packet from the public realm arrives at the RSIP gateway
`
`and it matches a given set of demultiplexing fields, then the RSIP
`
`gateway will tunnel it to the appropriate RSIP host. Id., 6-7.
`
`25.
`
`In this fashion, RSIP maintains the end—to-end integrity of IP
`
`communication sessions across addressing realms, and avoids some of the practical
`
`difficulties known to be present in NAT deployments.
`
`Exhibit 2010
`Page 2010-11
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`RSIP WITH IPSEC
`
`26.
`
`RFC 3104 contemplates an extension to RSIP that supports security
`
`with end-to-end IPSEC, thus overcoming another NAT-related drawback, for static
`
`network connections. EX. 2004 (RFC 3104), 2—3. The diagram below is
`
`instructive with respect to the operation of RSIP with IPSEC. Id. , 2 (The diagram
`
`below may also be referred to as the Core Diagram to distinguish it from the
`
`diagram in the Roadwarrior scenario, which shall be referred to as the Roadwarrior
`
`Diagram).
`
`RSIP client
`
`RSIP server
`
`Xa
`
`+ ------------ +
`
`Na
`
`Nb
`Nbl
`
`+ ------------ +
`
`Host
`
`Yb
`
`space— ] ——————— {Y}
`[X] ------ I Adér space I — ——- [N3 ----- I Add:
`l
`I
`A
`I
`21132
`f
`B
`+ ———————————— +
`.
`.
`.
`+ ———————————— +
`
`27. As described in RFC 3104:
`
`Hosts X and Y belong to different address spaces A and B,
`
`respectively, and N is an RSIP server. N has two addresses: Na on
`
`address space A, and Nb on address space B. For example, A could be
`
`a private address space, and B the public address space of the general
`
`Internet. Additionally, N may have a pool of addresses in address space
`
`B which it can assign to or lend to X. 161., 3.
`
`28.
`
`In this scenario, host X is using address Xa from address space A, and
`
`host Y is using address Yb from address space B.
`
`Exhibit 2010
`Page 2010-12
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`29. An RSIP session is established between host X and RSIP server N.
`
`Using this RSIP session, RSIP server N is able to allocate host X one of its
`
`addresses from address space E (e.g., Nb) along with one or more port numbers
`
`and one or more IPSEC security parameter indexes (SPIs). This is accomplished
`
`by host X using address Xa to transmit an AS SIGN_REQUEST_RSIPSEC request
`
`message to address Na ofRSIP server N, and RSIP server N providing these values
`
`in an AS SIGN_RESPONSE_RSIPSEC response message transmitted from address
`
`Na to address Xa. 161., 7-9.
`
`30.
`
`The format of the ASSIGN_RESPONSE_RSIPSEC response message
`
`is shown below (see EX. 1004, 9):
`
`<ASSIGN_RESPONSE_RSIPSEC> :.
`
`<Version>
`
`(Message Type)
`
`<Overall Length>
`<Client
`ID>
`
`<Bind ID>
`
`<Address {local)>
`
`<Ports (local)>
`
`<Address
`
`(remote)>
`
`<Ports (remote)>
`
`<SPI>
`
`<Lease Time>
`
`<Tunnel Type>
`
`[Address
`
`(tunnel endpoint)]
`
`[Message Countex]
`
`31.
`
`In the response message, RSIP server N uses the “Address (local)”
`
`and “Ports (local)” fields to allocate to host X a local address and accompanying
`
`Exhibit 2010
`Page 2010-13
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`local ports from address space B. See, e.g., Ex. 1004. The SPI(s) are provided in
`
`the SP1 parameter of the ASSIGN_RESPONSE_RSIPSEC message. Id, 9. Each
`
`SP1 can later be used in IPSEC packets transmitted from host Y to host X. SPIs
`
`are 32-bit numbers that uniquely identify a unidirectional logical security
`
`association between host X and host Y.
`
`32.
`
`The format of the ASSIGN__REQUEST_RSIPSEC request message is
`
`shown below (see EX. 1004, 8):
`
`<ASSIGN_REQUEST_RSIPSEC> ::= <Version>
`<Message Type>
`
`<Overall Length>
`(Client ID>
`
`<Address
`
`(local)>
`
`<Ports (local)>
`
`(Address (remote)>
`
`(Ports (remote)>
`<SPI>
`
`[Message Counter]
`[Lease Time}
`
`[Tunnel Type}
`
`33.
`
`The ASSIGN_REQUEST_RSIPSEC request message is sent by host
`
`X to request a binding such that RSIP server N allocates resources and establishes
`
`an RSIP session with host X. As noted above, the message also requests
`
`parameters that can be used to establish an IPSEC session between host X and host
`
`Y. In the ASSIGN_REQUEST_RSIPSEC request message, these parameters do
`
`not include Xa, the address of host X, and they do not set forth the current address
`
`Exhibit 2010
`Page 2010-14
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`of host X within address space A or a new address of host X within address space
`
`A. On the contrary, the <Address (local)> and the <Port (local)> parameters
`
`represent the address Nb and related port numbers of RSIP server N. The
`
`<Address (remote)> and the <Port (remote)> parameters set forth the address Yb
`
`of remote host Y. In sum, the AS SIGN_REQUEST_RSIPSEC does not provide
`
`addressing information for host X in address space A and cannot be used to change
`
`the address of host X that is use in an RSIP session (i.e., Xa) with RSIP server N.
`
`34. As noted previously, when using the allocated local address (e.g., Nb)
`
`to communicate with a node in address space B, host X must tunnel packets over
`
`address space A to RSIP server N. Ex. 1019, 6—7. Thus, addresses in “tunnel
`
`headers of outbound packets from X to Y, given that X has been assigned Nb” are:
`
`+ ————————— + ————————— + ————————— +
`
`i X —> Na I Nb —> Y ] payload I
`+ ————————— + ————————— + ————————— +
`
`35.
`
`The outer header (e. g., IP header) is shown on the left with a source
`
`address of X (more precisely, Xa) and a destination address of Na. Id, 7. This
`
`outer header serves to carry the encapsulated inner packet from host X to RSIP
`
`server N without exposing addresses from address space B within address space A.
`
`The inner header (e. g., another IP header) is shown in the middle with a source
`
`address of Nb and a destination address of Y (more precisely, Yb). Id. This inner
`
`Exhibit 2010
`Page 2010-15
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`host Y. Id. In the opposite direction (described but not illustrated in RFC 3102),
`
`the tunneled packet from RSIP server N will have an outer header with a source
`
`address of Na and a destination address of Xa. The inner header of this packet will
`
`have a source address of Yb and a destination address of Nb.
`
`36. Using an SP1 and Nb, an IPSEC session is negotiated between host X
`
`and host Y so that a security association from host Y to host X will use the SP1.
`
`Ex. 1004, 5. Particularly, host X instructs host Y to use the SP1 provided to host X
`
`by RSIP server N — “[o]nce N and X make sure that the SP1 is unique within both
`
`of their SPI spaces, X communicates its value to Y as part of the IPsec security
`
`association establishment process.” Id.
`
`37.
`
`This causes an IPSEC packet transmitted from host Y to Nb to include
`
`an IP header followed by either an IPSEC AH or ESP header, the latter containing
`
`the SPI. This can be represented as I Yb—>Nb I SP1 I payload I, where Yb is the
`
`source address in the IP header, Nb is the destination address in the IP header, and
`
`SPI is the SPI value in the AH or ESP header. The AH or ESP header encapsulates
`
`and protect a payload, which may be a TCP or UDP segment or an inner IP header
`
`containing a full IP packet depending on whether IPSEC transport mode or tunnel
`
`mode is employed. See, e.g., Ex. 1001, 3:13—43.
`
`38.
`
`The combination of Nb and the SP1 uniquely identifies host X, since
`
`this combination is unique at RSIP server N. Ex. 1004, 5. Accordingly, RSIP
`
`Exhibit 2010
`Page 2010-16
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`server N encapsulates this incoming packet in another IP header and tunnels the
`
`encapsulated packet to host X. Id. This can be represented as | Na—>Xa I Yb->Nb I
`
`SPI | payload |, where Na is the source IP address of the outer IP header, Xa is the
`
`destination address in the outer IP header, and where Yb, Nb, and SP1 remain the
`
`exactly same as they were in the packet received by RSIP server N from host Y.
`
`39.
`
`In the opposite direction, host X transmits IPSEC packets to host Y by
`
`tunneling these packets to RSIP server N. The SPI value does not need to be
`
`negotiated with RSIP server N for these packets because it is not being used to
`
`uniquely identify a host. Notably, when IPSEC is used in tunnel mode, this means
`
`that a double tunnel exists between host X and RSIP server N.
`
`CLAIM CONSTRUCTION
`
`40.
`
`I understand that, in this proceeding, claims of the ’494 Patent are to
`
`be given their ordinary and customary meaning, in light of the specification and
`
`prosecution history, as would have been read by a POSITA.
`
`41.
`
`From my review of the Decision Granting Institution, I understand
`
`that the Board did not specifically construe the claim term “unique identity,” and
`
`partially adopted Patent Owner’s proposed construction of the term “mobile
`
`computer,” agreeing that it required “moving from one network to another.”
`
`Decision Granting Institution of Inter Partes Review [Dec.], pp. 8-11.
`
`Specifically, the Board stated: “[W]e agree with Patent Owner that the ’494 patent
`
`Exhibit 2010
`Page 2010-17
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`teaches that mobility “mean[s] moving from one network to another.” Instn., Paper
`
`7, at 10—1 1. Regarding this term, the Board noted that the ’494 patent describes
`
`mobility at 4:34—38 and sending a signaling request to change addresses at 7:56—
`
`8:10.1d.,11.
`
`42.
`
`This declaration employs the assumption that the “mobile computer”
`
`recited in the claims moves from one network to another.
`
`A POSITA WOULD HAVE CONCLUDED THAT THE RSIP
`
`FRAMEWORK OF RFC 3104 DOES NOT TEACH OR SUGGEST
`
`HOST MOBILITY AS DEFINED IN THE ’494 PATENT
`
`A.
`
`The ’494 Patent Addresses the Deficiencies of IPSEC in the
`
`Presence of Host Mobility
`
`43.
`
`A POSITA would have understood that the ’494 Patent solves
`
`problems related to host mobility in the presence 'of IPSEC. Notably the
`
`Background of the ’494 Patent describes various technical difficulties associated
`
`with using standard IPSEC for host mobility. For example, it notes that “[t]he
`
`problem with standard IPSec is thus that it has been designed for static
`
`connections.” Ex. 1001, 4:39-40. Further, the Background contemplates a
`
`scenario in which “a standard IPSec security gateway, which is used by a mobile
`
`terminal e.g. for remote access.” Id, 4:48-49. Thus, “[s]tandard IPSec does not
`
`work well in the scenario [because] IPSec connections are bound to fixed
`
`addresses, [and] the mobile terminal must establish a new IPSec connection from
`
`each point of attachment.” Id, 4:60-63.
`
`Exhibit 2010
`Page 2010-18
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`B.
`
`RFC 3104 is Silent Regarding Host Mobility
`
`44.
`
`I am a co—author of RFC 3104 (Ex. 1004), RFC 3102 (Ex. 1019), and
`
`RFC 3103 (Ex. 2004). See Ex. 1004, 1; Ex. 1019, 1, Ex. 2004, 1.
`
`I shall be
`
`framing any opinions in terms of what a POSITA would have understood these
`
`documents to teach at the time of the invention in 2002 or 2003. I will also be
`
`setting forth certain facts that are within my personal knowledge because I was
`
`involved in creating these RSIP-related documents.
`
`45. Dr. Goldschlag states that “RSIP allows a host the mobility to move
`
`between different networks and bind to different network addresses.” Ex. 1002, fl
`
`63. I respectfully disagree with this position.
`
`46.
`
`RSIP was not developed or intended to be used to solve problems
`
`related to mobility. A POSITA would have understood that this is the case because
`
`there is no emphasis or detailed discussion in RFC 3104 on host mobility.
`
`47.
`
`Indeed, RSIP is described as an “alternative to NAT in which the end—
`
`to-end integrity of packets is maintained.” Ex. 1019, 1. There is no discussion of
`
`host mobility with address changes being the goal of RSIP. Such changes would
`
`have violated this goal of maintaining end-to—end integrity of packets.
`
`48. Given this observation, it is my opinion that Dr. Goldschlag’s
`
`statement that “RSIP allows a host the mobility to move between different
`
`networks and bind to different network addresses” is unsupported. Particularly,
`
`Exhibit 2010
`Page 2010-19
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`RFC 3104 does not teach or suggest to a POSITA how such mobility would be
`
`handled by either a host or an RSIP server, and Dr. Goldschlag has failed to
`
`provide any reasoning to explain or make up for this discrepancy.
`
`C.
`
`RFC 3104 Does Not Teach a POSITA That Host X or Host Y of
`
`the RSIP Model Changes Addresses as Described by Dr.
`Goldschlag
`
`49.
`
`Dr. Goldschlag goes on to assert that “a POSITA would have also
`
`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.”
`
`Ex. 1002, 11 91. I disagree with his opinion.
`
`RSI? client
`
`RSIP server
`
`Xa
`
`Na
`
`Nb
`
`+ ———————————— +
`
`Nbl
`
`+ ———————————— +
`
`Host.
`
`Yb
`
`[X3 ------ I Add: space | — ——— [N3 ————— ] Add]: space I ------- {Y}
`1
`A
`1
`Nb:
`5
`B
`l
`+ ———————————— +
`.
`.
`.
`+ ———————————— +
`
`50.
`
`For sake of convenience, I have reproduced the RSIP model diagram
`
`(Core Diagram) from RFC 3104 above. Ex. 1004, 2. As discussed above, “RSIP
`
`allows X (and any other hosts on address space A) to reuse Nb.” Id, 3.
`
`51.
`
`Regarding host X, this model does not specify how address Xa is
`
`assigned to host X. Indeed, RFC 3104 was intentionally open-ended with regard to
`
`Exhibit 2010
`Page 2010-20
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`the assignment of address Xa for this model because it was beyond the scope of the
`
`RSIP protocol. As far as RSIP is concerned, the assignment is assumed to exist.
`
`52.
`
`Further, RFC 3104 treats the assignment of address Xa to host X as
`
`static for the duration of the RSIP session between host X and RSIP server N, as
`
`well as during the overlapping duration of the IPSEC session between host X and
`
`host Y. Notably, RFC 3104 does not discuss address Xa changing during an RSIP
`
`session, which a POSITA would understand to mean that address Xa does not
`
`change during these sessions.
`
`53.
`
`Furthermore, address Nb — as reused by host X — would also be static
`
`for at least the duration of the IPSEC session. Indeed, the ’494 Patent correctly
`
`states that “IPSec connections are bound to fixed addresses.” Ex. 1001, 4:61.
`
`Further, a stated goal of RSIP is to provide an “alternative to NAT in which the
`
`end-to—end integrity of packets is maintained.” Ex. 1019, 1. RFC 3104 requires
`
`that Nb, the destination IP address of IPSEC packets transmitted from host Y to
`
`host X, remain fixed for these reasons, and because Nb is used as a demultiplexing
`
`parameter. Ex. 1004, 5. To that end, “[i]f N cannot find an appropriate mapping
`
`[using the destination IP address of such an incoming packet], it MUST discard the
`
`packet.” Id. A POSITA would understand that discarding IP packets in such a
`
`fashion would render the RSIP-enabled IPSEC session inoperable, and therefore
`
`that address Nb must also be static for the duration of the session.
`
`Exhibit 2010
`Page 2010-21
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`54.
`
`Regarding host Y, Dr. Goldschlag provides no rationale for why a
`
`POSITA would understand that it’s “address would change.” Once more, the
`
`requirement that “IPSec connections are bound to fixed addresses” and the goal of
`
`RSIP to maintain the end-to-end integrity of packets contradicts Dr. Goldschlag’s
`
`statements. EX. 1001, 4261,'EX. 1019, 1. Instead, a POSITA would have
`
`recognized that changes to Yb, like changes to Nb, would render the RSIP-enabled
`
`IPSEC session inoperable.
`
`55.
`
`Furthermore, RFC 3104 clearly states that “Y is not RSIP aware.” Ex.
`
`1004, 5. Thus, even if the address of Y did change, such changes would be beyond
`
`the control of RSIP and outside the scope of RFC 3104. As an RSIP—unaware
`
`device, host Y would not have an RSIP session with RSIP server N, much less be
`
`able to send a signal to RSIP server N indicating that the former’s address has
`
`changed so as to “update” such a session.
`
`D.
`
`RFC 3104 Does Not Teach a POSITA That Host X or Host Y of
`
`the Roadwarrior Scenario Changes Addresses as Described by
`Dr. Goldschlag
`
`56.
`
`RFC 3104 also describes a variation of the RSIP model called the
`
`“Roadwarrior scenario.” Id, 16. For sake of convenience, the diagram for this
`
`scenario (Roadwarrior Diagram) is reproduced below.
`
`Exhibit 2010
`Page 2010-22
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`+ ————————— +
`
`+ ———————————— +
`
`+ ~~~~~~~~~~ +
`
`I
`IPsec
`I
`I
`ICorporate
`I
`IRSIP
`I
`+~--+ peer Y
`Iclient X +-— .......... ——+Firewall
`I
`I
`I
`(user’s
`I
`I
`public
`I and
`I
`+ ————————— +
`Internet
`IRSIP server I
`I desktop)
`1
`l N
`s
`l
`+ ~~~~~~~~~~~~ +
`+ —————————— +
`
`private corporate
`network
`
`57.
`
`RFC 3104 describes this section as follows:
`
`Using mechanisms not specified in this document, the RSIP
`
`client in the laptop engages in an RSIP authentication and authorization
`
`phase with the RSIP server at
`
`the firewall. After that phase is
`
`completed, the IPsec extensions to RSIP defined here are used to
`
`establish an IPsec session with a peer, Y,
`
`that resides within the
`
`corporation’s network. Y could be, for example, the remote user’s usual
`
`desktop when at the office. The corporate firewall complex would use
`
`RSIP to selectively enable IPsec traffic between internal and external
`
`systems. Id. (emph. added).
`
`58. Dr. Goldschlag contends that “at least the computer connected to the
`
`public Internet (e.g., host Y in RFC3lO4’s primary discussion—see, e.g., id, 3), as
`
`discussed in this scenario, would be a ‘mobile computer’ that sends IPSec packets
`
`to its peer Via RSIP server N.” Ex. 1002, II 93. Here, it appears that Dr.
`
`Goldschlag has incorrectly conflated the roles of host X and host Y.
`
`59.
`
`In the RSIP model discussed above (i.e., for the Core Diagram), host
`
`X is disposed within address space A and host Y is disposed within address space
`
`Exhibit 2010
`Page 2010-23
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`
`
`B. Examples within RFC 3104 describe address space A being a private address
`
`space and address space B being a public address space. Ex. 1004, 3, 13.
`
`60. 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. This is due to the fact that: (i) the RSIP client negotiates and
`
`establishes RSIP and IPSEC sessions with RSIP server N and host Y, respectively,
`
`while host Y is RSIP-unaware, and (ii) that RSIP server N must demultiplex and
`
`tunnel incoming IPSEC packets from host Y. In both the RSIP model (Core
`
`Diagram) and the Roadwarrior scenario (Roadwarrior Diagram), the RSIP client is
`
`explicitly host X. Id. 3, 5, 16. Therefore, Dr. Goldschlag’s statement equating
`
`“the computer connected to the public Intern