Case IPR2019-00824
`Patent 9,712,502
`
`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
`Patent 9,712,502
`
`EXHIBIT 2010
`
`DECLARATION OF MICHAELS. BORELLA
`
`Exhibit 2010
`Page 2010-1
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`Patent 9,712,502
`
`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
`Patent 9,712,502
`
`EXHIBIT 2010
`
`DECLARATION OF MICHAELS. BORELLA
`
`Exhibit 2010
`Page 2010-1
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`
`TABLE OF CONTENTS
`
`Page
`
`I.
`
`INTRODUCTION ....................................................................................... 1
`QUALIFICATIONS .................................................................................... 2
`II.
`III. BASES OF OPINIONS ............................................................................... 4
`IV. ORDINARY SKILL IN THE ART ........................................................... 4
`NETWORK ADDRESS TRANSLATION ................................................ 6
`V.
`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 '502 PATENT .................. 15
`
`A. The '502 Patent Addresses the Deficiencies ofIPSEC in the
`Presence of Host Mobility.................................................................. 15
`B. RFC 3104 is Silent Regarding Host Mobility .................................... 16
`C. RFC 3104 Does Not Teach a POSIT A 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 POSIT A Would Have Understood That the
`ASSIGN_REQUEST_IPSEC Message is Not Used to Provide an
`Address of Address space A to Host X .............................................. 23
`
`1
`
`Exhibit 2010
`Page 2010-2
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`
`X.
`
`A POSITA WOULD HA VE UNDERSTOOD THAT RFC
`DOCUMENTS ARE INTENDED TO BE READ IN COMBINATION
`WITH ONE ANOTHER ...................•....................................................... 26
`
`XI.
`
`CONCLUSION .......................................................................................... 27
`
`11
`
`Exhibit 2010
`Page 2010-3
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`
`I.
`
`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 U.S. 9,712,502 ("the '502 Patent") in the IPR2019-00824
`
`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 truthfully.
`
`3.
`
`A detailed record of my professional qualifications can be found in
`
`Exhibit 2009 and is summarized in Section II, infra.
`
`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 '502 Patent.
`
`1
`
`Exhibit 2010
`Page 2010-4
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`
`6.
`
`I wish to disclose that I am a co-author ofRFC 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.
`
`II.
`
`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,
`
`2
`
`Exhibit 2010
`Page 2010-5
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`
`operating systems, wireless networks, mobile applications, and cloud computing.
`
`Further details are contained in my C.V. 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-00824 proceeding. Most notably, I am co(cid:173)
`
`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 U.S. 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 M.S. in computer science from the same university in
`
`1994, and a B.S. in computer science and technical communications (with
`
`distinction) from Clarkson University in 1991.
`
`3
`
`Exhibit 2010
`Page 2010-6
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`
`12. My academic work includes two years as tenure-track faculty in the
`
`computer science department ofDePaul University, as well as eight years as an
`
`adjunct professor in the electrical engineering department of Northwestern
`
`University.
`
`III.
`
`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.
`
`IV.
`
`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/FI2003/000045 from which
`
`priority was asserted by original U.S. Patent Application No. 10/500,930. U.S.
`
`U.S. Patent Application No 10/500,930 issued as U.S. 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
`
`4
`
`Exhibit 2010
`Page 2010-7
`IPR2019-00824, 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 POSIT A 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 '502 Patent.
`
`15.
`
`I understand that, in assessing the level of skill of a POSIT A, 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 '502 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, il 31. In my view, this is a reasonable standard for the
`
`level of ordinary skill in the art for the present matter.
`
`1 7.
`
`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
`
`5
`
`Exhibit 2010
`Page 2010-8
`IPR2019-00824, 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 POSIT A at the time of the invention.
`
`V.
`
`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
`
`6
`
`Exhibit 2010
`Page 2010-9
`IPR2019-00824, 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.
`
`VI.
`
`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) from 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
`
`7
`
`Exhibit 2010
`Page 2010-10
`IPR2019-00824, 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. Id., 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 of port 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 MA YNOT use address
`I 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.
`
`8
`
`Exhibit 2010
`Page 2010-11
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`
`VII.
`
`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 IP SEC. 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
`
`Host
`
`Xa
`
`Na
`
`Nb
`Nb1 +------------+
`+------------+
`[X]------1 Addr space l----[N]-----1 Addr space 1-------[Y]
`I
`I B
`I
`I A
`Nb2
`+------------+
`+------------+
`
`Yb
`
`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. Id., 3.
`
`28.
`
`In this scenario, host Xis using address Xa from address space A, and
`
`host Y is using address Yb from address space B.
`
`9
`
`Exhibit 2010
`Page 2010-12
`IPR2019-00824, 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 B ( 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 ASSIGN_REQUEST_RSIPSEC request
`
`message to address Na ofRSIP server N, and RSIP server N providing these values
`
`in an ASSIGN_RESPONSE_RSIPSEC response message transmitted from address
`
`Na to address Xa. Id., 7-9.
`
`30. The format of the ASSIGN_RESPONSE_RSIPSEC response message
`
`is shown below (see Ex. 1004, 9):
`
`<1tSSIGN 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 Counter]
`
`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
`
`10
`
`Exhibit 2010
`Page 2010-13
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`
`local ports from address space B. See, e.g., Ex. 1004. The SPI(s) are provided in
`
`the SPI parameter of the ASSIGN_RESPONSE_RSIPSEC message. Id., 9. Each
`
`SPI 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
`
`11
`
`Exhibit 2010
`Page 2010-14
`IPR2019-00824, 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 ofRSIP server N. The
`
`<Address (remote)> and the <Port (remote)> parameters set forth the address Yb
`
`of remote host Y. In sum, the ASSIGN_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:
`
`+---------+---------+---------+
`IX-> Na I Nb-> YI payload I
`+---------+---------+---------+
`
`35. The outer header (e.g., IP header) is shown on the left with a source
`
`address ofX (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 ofNb and a destination address ofY (more precisely, Yb). Id. This inner
`
`header represents the end-to-end encapsulated packet that host Xis transmitting to
`12
`
`Exhibit 2010
`Page 2010-15
`IPR2019-00824, 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 ofXa. The inner header of this packet will
`
`have a source address of Yb and a destination address of Nb.
`
`36. Using an SPI 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 SPI.
`
`Ex. 1004, 5. Particularly, host X instructs host Y to use the SPI provided to host X
`
`by RSIP server N - "[ o ]nee N and X make sure that the SPI is unique within both
`
`of their SPI spaces, X com.m.unicates its value to Y as part of the IP sec security
`
`association establishment process." Id.
`
`3 7. This causes an IP SEC 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 SPI 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 m.ay 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 em.ployed. See, e.g., Ex. 1001, 3:13-4:3.
`
`38. The combination of Nb and the SPI uniquely identifies host X, since
`
`this combination is unique at RSIP server N. Ex. 1004, 5. Accordingly, RSIP
`
`13
`
`Exhibit 2010
`Page 2010-16
`IPR2019-00824, 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 I Na->Xa I Yb->Nb I
`
`SPI I payload I, 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 SPI remain the
`
`exactly same as they were in the packet received by RSIP server N from host Y.
`
`3 9.
`
`In the opposite direction, host X transmits IP SEC 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.
`
`VIII.
`
`CLAIM CONSTRUCTION
`
`40.
`
`I understand that, in this proceeding, claims of the '502 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 '502 patent
`
`14
`
`Exhibit 2010
`Page 2010-17
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`
`teaches that mobility "mean[ s] moving from one network to another." Instn., Paper
`
`7, at 10. Regarding this term, the Board noted that the '502 patent describes
`
`mobility at 4:35-37 and sending a signaling request to change addresses at 7:56-
`
`8:7. Id., 10-11.
`
`42. This declaration employs the assumption that the "mobile computer"
`
`recited in the claims moves from one network to another.
`
`IX.
`
`A POSITA WOULD HAVE CONCLUDED THAT THE RSIP
`FRAMEWORK OF RFC 3104 DOES NOT TEACH OR SUGGEST
`HOST MOBILITY AS DEFINED IN THE '502 PATENT
`
`A.
`
`The '502 Patent Addresses the Deficiencies oflPSEC in the
`Presence of Host Mobility
`
`43. A POSITA would have understood that the '502 Patent solves
`
`problems related to host mobility in the presence of IPSEC. Notably the
`
`Background of the '502 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:40-41. 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:49-50. 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 :61-64.
`
`15
`
`Exhibit 2010
`Page 2010-18
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`
`B.
`
`RFC 3104 is Silent Regarding Host Mobility
`
`44.
`
`I am a co-author ofRFC 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 POSIT A 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, ~
`
`66. 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.
`
`4 7.
`
`Indeed, RSIP is described as an "alternative to NAT in which the end(cid:173)
`
`to-end integrity of packets is maintained." Ex. 1019, 1. There is no discussion of
`
`host mobility with address changes being the goal ofRSIP. 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,
`
`16
`
`Exhibit 2010
`Page 2010-19
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`
`RFC 3104 does not teach or suggest to a POSIT A 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
`
`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, 1 92. I disagree with his opinion.
`
`RSIP client
`
`RSIP server
`
`Host
`
`Xa
`
`Na
`
`Nb
`Nb1 +------------+
`+------------+
`[X)------1 Addr space l----[N]-----1 Addr space 1-------(Y]
`I B
`I
`I A
`]
`Nb2
`+------------+
`+-------- ·---+
`
`Yb
`
`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
`
`17
`
`Exhibit 2010
`Page 2010-20
`IPR2019-00824, 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 IP SEC session between host X and
`
`host Y. Notably, RFC 3104 does not discuss address Xa changing during an RSIP
`
`session, which a POSIT A 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 '502 Patent correctly
`
`states that "IPSec connections are bound to fixed addresses." Ex. 1001, 4:62.
`
`Further, a stated goal ofRSIP 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 IP SEC 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]fN 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.
`
`18
`
`Exhibit 2010
`Page 2010-21
`IPR2019-00824, 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, 4:61, 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 ofY did change, such changes would be beyond
`
`the control ofRSIP 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
`
`5 6. 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.
`
`19
`
`Exhibit 2010
`Page 2010-22
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`
`
`+------------+ +----------+
`+---------+
`I
`IPsec
`!Corporate
`I
`IRSIP
`+---+
`peer Y
`!client X +-- .......... --+Firewall
`I
`(user's
`I
`I and
`public
`I
`jRSIP server I
`desktop)
`Internet
`+---------+
`I
`I N
`+------------+ +----------+
`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 Yin RFC3104'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, 193. 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
`
`20
`
`Exhibit 2010
`Page 2010-23
`IPR2019-00824, 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 understoo
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
