UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`
`
`
`APPLE INC.,
`Petitioner
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner
`
`____________________
`
`Case IPR2019-00825
`U.S. Patent No. 9,762,397
`____________________
`
`
`
`
`
`PETITION FOR INTER PARTES REVIEW OF
`U.S. PATENT NO. 9,762,397
`
`
`
`
`
`
`
`
`Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`
`TABLE OF CONTENTS
`
`
`I.
`
`II.
`
`III.
`
`
` The ’397 Patent ................................................................................................ 6 IV.
`
`Mandatory Notices (37 C.F.R. § 42.8(a)(1)) ................................................... 2
`Grounds for Standing (37 C.F.R. § 42.104(a)) ................................................ 3
`Identification of Challenge (37 C.F.R. § 42.104(b)) ....................................... 3
`A. Citation of Prior Art .................................................................................... 3
`B. Statutory Grounds for the Challenge .......................................................... 6
`
`A. Overview of the ’397 Patent ....................................................................... 6
`1. Brief Overview of IPSec ....................................................................... 7
`2. The ’397 patent focused on employing standard IPSec protocols to
`establish a single secure connection. ..................................................... 9
`3. The Examiner did not consider RFC3104 or Grabelsky. ....................12
`B. Level of Ordinary Skill in the Art ............................................................14
`C. Claim Construction ...................................................................................15
`1. “secure connection” ............................................................................15
`2. “unique identity” ..................................................................................16
`
`A. Ground 1: Claims 1 and 2 are unpatentable under 35 U.S.C. § 103 as
`obvious over RFC3104 and Grabelsky. ...................................................17
`1. Overview of RFC3104 ........................................................................17
`2. Overview of the Combination of RFC3104 and Grabelsky ................21
`3. The combination of RFC3104 and Grabelsky renders claim 1 obvious.
` 26
`4. The combination of RFC3104 and Grabelsky renders claim 2 obvious.
` 40
`
` Conclusion. ....................................................................................................42 VIII.
`
`
`
` Grounds of Unpatentability ...........................................................................17 VII.
`
`
`
`
`
`- i -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`
`EXHIBIT LIST
`
`Exhibit No.
`
`Description
`
`1001
`
`1002
`
`1003
`
`1004
`
`1005
`
`1006
`
`1007
`
`1008
`
`U.S. Patent No. 9,762,397 B2 to Vaarala et al., issued Sept. 12,
`2017
`
`Declaration of David Goldschlag, Ph.D. (“Goldschlag Decl.”)
`
`Prosecution History of U.S. Patent No. 9,762,397 B2
`
`RFC3104 - RSIP Support for End-to-end IPsec (Oct. 2001)
`
`U.S. Patent No. 7,032,242 B1 to Grabelsky et al., issued Apr. 18,
`2006
`
`Intentionally Left Blank
`
`Declaration of Ms. Sandy Ginoza
`
`Curriculum Vitae of David Goldschlag, Ph.D.
`
`1009-1010
`
`Intentionally Left Blank
`
`1011
`
`1012
`
`1013
`
`1014
`
`1015
`
`1016
`
`1017
`
`1018
`
`1019
`
`S. Frankel, Demystifying the IPsec Puzzle, Artech House, Inc., 2001
`
`RSIP Support for End-to-end IPsec (RFC3104), IETF Data Tracker
`
`RFC2026 - The Internet Standards Process -- Revision 3 (Oct.
`1996)
`
`Intentionally Left Blank
`
`RFC2401 - Security Architecture for the Internet Protocol (Nov.
`1998)
`
`RFC2402 - IP Authentication Header (Nov. 1998)
`
`RFC2406 - IP Encapsulating Security Payload (ESP) (Nov. 1998)
`
`RFC2409 - The Internet Key Exchange (IKE) (Nov. 1998)
`
`RFC3102 - Realm Specific IP: Framework (Oct. 2001)
`
`
`
`- ii -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`
`Description
`
`Prosecution History of U.S. Patent No. 8,346,949 B2
`
`
`Exhibit No.
`
`1020
`
`
`
`
`
`- iii -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`Apple Inc. petitions for inter partes review of claims 1 and 2 of United
`
`States Patent No. 9,762,397 to Vaarala et al. (Ex. 1001, “the ’397 patent”), titled
`
`“Method and System for Sending a Message Through a Secure Connection.” The
`
`Petition demonstrates that both claims of the ’397 patent are unpatentable.
`
`The ’397 patent purported to solve issues with Internet Protocol Security
`
`(IPSec) operability for mobile hosts. It did not. Rather, the alleged issues with
`
`IPSec presented by the ’397 patent were well-known and solved long before the
`
`earliest priority date of the ’397 patent. Ex. 1002, Goldschlag Decl., ¶¶45-52. In
`
`particular, the ’397 patent alleged that IPSec was designed for static connections,
`
`and therefore when a mobile host moved or changed its network address, IPSec
`
`provided no mechanism to alter parameters of the secure connection. Id.
`
`The ’397 patent alleged to solve these problems by establishing an end-to-
`
`end secure connection between two end hosts via an intermediate computer. But
`
`not only is this solution trivial, it was also explicitly disclosed by RFC3104 prior to
`
`the earliest priority date of the ’397 patent. Additionally, Grabelsky explains other
`
`well-known and simple elements of the claims that would have been known to a
`
`POSITA, such as data packet formats and use of translation tables.
`
`Accordingly, there is at least a reasonable likelihood that at least one claim
`
`of the ’397 patent is unpatentable, as shown herein. Therefore, Petitioner
`
`
`
`- 1 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`respectfully requests the Board institute trial on the grounds set forth herein and
`
`ultimately determine that all claims of the ’397 patent are invalid.
`
` Mandatory Notices (37 C.F.R. § 42.8(a)(1)) I.
`
`
`REAL PARTY IN INTEREST: The real party-in-interest of the Petition is
`
`Apple Inc. (“Apple”).
`
`RELATED MATTERS: Pursuant to 37 C.F.R. § 42.8(b)(2), the ’397 patent is
`
`currently being asserted in a district court litigation captioned as MPH
`
`Technologies Oy v. Apple Inc., Case No. 4:18-cv-05935-PJH (N.D. Cal.), filed
`
`September 27, 2018.
`
`Petitioner is concurrently filing Petitions for inter partes review against
`
`related U.S. Patent Nos. 8,346,949 (IPR2019-00822); 9,712,494 (IPR2019-00823);
`
`9,712,502 (IPR2019-00824); and 9,838,362 (IPR2019-00826).
`
`LEAD AND BACKUP COUNSEL: Pursuant to 37 C.F.R. § 42.8(b)(3) and
`
`42.10(a), Petitioner appoints Michael D. Specht (Reg. No. 54,463) as its lead
`
`counsel and Daniel S. Block (Reg. No. 68,395) and Steven M. Pappas (Reg. No.
`
`73,904) as its back-up counsel, all at the address: STERNE, KESSLER, GOLDSTEIN &
`
`FOX, P.L.L.C., 1100 New York Avenue, N.W., Washington, D.C., 20005, phone
`
`number (202) 371-2600 and facsimile (202) 371-2540.
`
`Service Information: Petitioners consent to electronic service by email at
`
`the email addresses: mspecht-PTAB@sternekessler.com, dblock-
`
`
`
`- 2 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`PTAB@sternekessler.com, spappas-PTAB@sternekessler.com, and
`
`PTAB@sternekessler.com.
`
` Grounds for Standing (37 C.F.R. § 42.104(a)) II.
`
`
`The undersigned and Apple certify that the ’397 patent is available for inter
`
`partes review. Pursuant to 37 C.F.R. § 42.104(a), Petitioner certifies that the ’397
`
`patent is available for inter partes review and that Petitioner is not barred or
`
`estopped from requesting an inter partes review challenging the claims of the ’397
`
`patent on the grounds identified herein.
`
`III.
`
`
`Identification of Challenge (37 C.F.R. § 42.104(b))
`A. Citation of Prior Art
`The ’397 patent claims the benefit of U.S. Patent No. 8,346,949 (“the ’949
`
`patent”). The PCT application corresponding to the ’949 patent was filed on
`
`January 21, 2003. The PCT application claims priority to a foreign application
`
`filed in Finland on January 22, 2002.1 Apple cites the following prior art
`
`references:
`
`“RFC3104: RSIP Support for End-to-end IPsec,” by Gabriel Montenegro
`
`and Michael Borella (Ex. 1004, “RFC3104”) is prior art under at least pre-AIA 35
`
`U.S.C. §§ 102(a) and 102(b) because it was published at least as of October 2001,
`
`1 Apple does not acquiesce that the ’397 patent is entitled to a priority date
`
`based on the foreign filed application.
`
`
`
`- 3 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`more than one year prior to the effective U.S. filing date of the ’397 patent.2 More
`
`specifically, RFC3104 was made publicly available no later than October 2001
`
`such that interested individuals, including POSITAs, could locate and obtain
`
`RFC3104. SeeBlue Calypso, LLC v. Groupon, Inc., 815 F.3d 1331, 1348 (Fed. Cir.
`
`2016). RFC3104 specifically includes this date on its face, as well as every
`
`subsequent page. See RFC3104.
`
`This date of publication is confirmed by Ms. Sandy Ginoza, custodian of
`
`records relating to the RFC Series managed by the Internet Engineering Task Force
`
`(IETF). Ex. 1007, Ginoza Decl., ¶1, 10. Ms. Ginoza is Director of the RFC
`
`Production Center, which is part of the “RFC Editor” function and is responsible
`
`for preparing documents for publication and placing files in an online repository as
`
`part of the authoritative RFC Series. Id., ¶1.
`
`Ms. Ginoza explains that “RFCs are kept in an online repository in the
`
`course of the RFC Editor’s regularly conducted business activity,” and “[i]t is the
`
`regular practice of the RFC Editor to make and keep the RFC records.” Id., ¶¶9-10.
`
`
`2 For the purposes of 35 U.S.C § 102(b), the relevant date to establish a
`
`reference as prior art to a patent is the “date of the application for patent in the
`
`United States” (i.e. the effective U.S. filing date), not a patent’s foreign priority
`
`date.
`
`
`
`- 4 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`Ms. Ginoza further testifies that “[b]ased on the business records for the RFC
`
`Editor and the RFC Editor’s course of conduct in publishing RFCs,” RFC3104 was
`
`published “no later than October 2001.” Id., ¶12. Once published, it was
`
`“reasonably accessible to the public either on the RFC Editor website or via FTP
`
`from a repository.” Id.. For example, Ms. Ginoza testifies that RFC3104 was
`
`“indexed and placed in a public repository.” Id., ¶¶7-8. Thus, Ms. Ginoza confirms
`
`that RFC3104 was made publicly available and accessible no later than October
`
`2001.
`
`Petitioner’s expert, Dr. Goldschlag, additionally states that anyone
`
`interested, including a POSITA, would have had access to, and would have been
`
`able to locate RFC3104 no later than October 2001. Goldschlag Decl., ¶¶6-8.
`
`Indeed, the purpose of publishing RFCs was to publicly solicit input from
`
`POSITAs. Id. And, finally, the IETF data tracker further supports that RFC3104
`
`published as of October 1, 2001. Ex. 1012, IETF Data Tracker, 0001, 0003;
`
`Goldschlag Decl., ¶6.
`
`Accordingly, RFC3104 was published and available no later than October
`
`2001.
`
`U.S. Patent No. 7,032,242 to Grabelsky et al. (Ex. 1005, “Grabelsky”),
`
`titled “Method and System for Distributed Network Address Translation with
`
`Network Security Features,” is prior art under at least pre-AIA 35 U.S.C. § 102(e)
`
`
`
`- 5 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`because it was filed on March 17, 1999, prior to the earliest possible priority date
`
`of the ’397 patent.
`
`Statutory Grounds for the Challenge
`
`B.
`Petitioner requests review of claims 1 and 2 on the following ground:
`
`Ground 1: Claims 1 and 2 are unpatentable under 35 U.S.C. § 103 as
`
`obvious over RFC3104 and Grabelsky.
`
` The ’397 Patent IV.
`
`
`A. Overview of the ’397 Patent
`The ’397 patent is directed to general techniques for “secure forwarding of a
`
`message from a first computer to a second computer.” Ex. 1001, ’397 patent,
`
`Abstract. The ’397 patent includes a lengthy technical background discussing “a
`
`need to protect data and resources from disclosure, to guarantee the authenticity of
`
`data, and to protect systems from network based attacks.” Id., 1:34-36. The ’397
`
`patent primarily discusses these concerns in terms of a “mobile host,” where the
`
`term “mobile” not only refers to physical mobility, but rather to “moving from one
`
`network to another, which can be performed by a physically fixed terminal as
`
`well.” Id., 4:17-34.
`
`The ’397 patent acknowledges that “IP security protocols (IPSec) provides
`
`the capability to secure communications between arbitrary hosts,” but “[t]he
`
`problem with standard IPSec is [] that it has been designed for static connections.”
`
`Id., 1:50-51, 4:35-36. Thus, when a host is mobile, the patent alleges that IPSec
`
`
`
`- 6 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`provides no mechanism to alter parameters of the secure connection. Id., 4:37-39.
`
`Because of this, the patent alleges that existing solutions employing IPSec “either
`
`employ extra tunneling, causing extra packet size overhead, or use separate
`
`tunnels, causing potential security problems in the intermediate host(s) that
`
`terminate such tunnels.” Id., 6:15-18. However, numerous solutions already existed
`
`in the prior art that addressed these alleged problems in substantially the same way
`
`as the ’397 patent.
`
`Brief Overview of IPSec
`
`1.
`The specification of the ’397 patent focuses on implementation of IPSec
`
`protocols to establish secure connections between devices. See, e.g., ’397 patent,
`
`7:1-4.
`
`IPSec is a well-known security protocol that “provides the capability to
`
`secure communications between arbitrary hosts, e.g., across a LAN, across private
`
`and public wide area networks (WANs)…” Id., 1:50-53; Goldschlag Decl., ¶33.
`
`“[A]cross the internet IPSec can be used in different ways, such as for building
`
`secure virtual private networks, to gain a secure access to a company network, or
`
`to secure communication with other organisations, ensuring authentication and
`
`confidentiality and providing a key exchange mechanism.” ’397 patent, 1:53-58;
`
`Goldschlag Decl., ¶33.
`
`
`
`- 7 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`A key concept of IPSec is a security association (SA), and the ’397 patent
`
`explains that “[a] security association is a one-way relationship between a sender
`
`and a receiver that offers security services to the traffic carried on it.” ’397 patent,
`
`2:15-20. “[I]f a secure two way relationship is needed, then two security
`
`associations are required.” Id., 2:19-20. The ’397 patent explains that “[a] security
`
`association is uniquely identified by three parameters. The first one, the Security
`
`Parameters Index (SPI), is a bit string [that] is carried in AH and ESP headers to
`
`enable the receiving system to select the SA under which a received packet will be
`
`processed. IP destination address is the second parameter, which is the address of
`
`the destination end point, of the SA, which may be an end user system or a
`
`network system such as a firewall or a router. The third parameter, the security
`
`protocol identifier indicates whether the association is an AH or ESP security
`
`association.” Id., 2:35-45; Goldschlag Decl., ¶¶35-36.3
`
`Two IPSec security services are typically used, including “an authentication
`
`protocol designated by the header of the protocol, Authentication Header (AH),
`
`and a combined encryption/authentication protocol designated by the format of the
`
`packet for that protocol, Encapsulating Security Payload (ESP).” ’397 patent, 2:5-
`
`11; Goldschlag Decl., ¶34. IPSec services further support two modes: “transport
`
`
`3 Emphasis added unless otherwise indicated in this Petition.
`
`
`
`- 8 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`mode” and “tunnel mode.” ’397 patent, 3:8-9; Goldschlag Decl., ¶37. “Transport
`
`mode provides protection primarily for upper layer protocols and extends to the
`
`payload of an IP packet,” while “Tunnel mode provides protection to the entire IP
`
`packet.” Id., 3:10-20. The ’397 patent makes use of these IPSec protocols and
`
`modes in the same way as the prior art. Goldschlag Decl., ¶38.
`
`2.
`
`The ’397 patent focused on employing standard IPSec
`protocols to establish a single secure connection.
`
`The ’397 patent purports to “develop a method for forwarding secure
`
`messages between two computers, especially, via an intermediate computer.” ’397
`
`patent, 6:22-25. The ’397 patent illustrates an example telecommunication network
`
`in Figure 1:
`
`’397 patent, FIG. 1 (annotated).
`
`
`
`
`
`- 9 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`The example network includes “a first computer, here a client computer 1
`
`served by an intermediate computer, here as a server 2, and a host computer 4, that
`
`is served by the second computer, here a security gateway (SGW) 3.” ’397 patent,
`
`9:65-10:3. Server 2 acts as the intermediate computer between client computer 1
`
`and security gateway 3.
`
`The ’397 patent describes that “an IPSec connection is formed between the
`
`client computer 1 (the first computer) and the security gateway 3 (the second
`
`computer).” Id., 10:40-42. To create the IPSec connection, “a SA [(Security
`
`Association)] (or usually a SA bundle) is formed between the respective computers
`
`with a preceding key exchange. The key exchange between the first and the second
`
`computer can take place manually or it can be performed with an automatic key
`
`exchange protocol such as the IKE [(Internet Key Exchange)] protocol.” Id.,
`
`10:42-48. As described above, the patent explains that an IPSec “security
`
`association is a one-way relationship between a sender and a receiver that offers
`
`security services to the traffic carried on it.” Id., 2:16-20.
`
`Following establishment of an SA, “[m]essages to be sent to the host
`
`terminal 4 from the client computer 1 are first sent to the server 2, wherein an
`
`IPSec translation and an IKE translation takes place. After that the message can be
`
`sent to the security gateway 3, which sends the message further in plain text to the
`
`host terminal 4.” Id., 10:54-58. A message sent to the intermediate computer (e.g.,
`
`
`
`- 10 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`server 2) includes “a unique identity and a destination address.” Id., 6:38-40. This
`
`unique identity and destination address “are used to find an address to the second
`
`computer” (e.g., security gateway 3). Id., 6:40-43. When the address of the second
`
`computer is found, the unique identity and current destination address of the
`
`message are substituted with another unique identity and the determined
`
`destination address of the second computer. Id., 6:43-46. The message is then
`
`forwarded from the intermediate computer (e.g., server 2) to the second computer
`
`(e.g., security gateway 3). Id., 6:46-47.
`
`During prosecution of the ’949 patent, of which the ’347 patent is a
`
`continuation, the Applicant explained that the purported unique feature of the
`
`invention is that “the secure connection is established all the way between the first
`
`computer and the second computer via the intermediate computer by exchanging
`
`keys….” Ex. 1020, ’949 Patent Prosecution History, 0237. The Applicant
`
`explained that this allows “a secure message, sent from the first computer to the
`
`intermediate computer, [to] be modified by the intermediate computer so that it can
`
`be forwarded from the intermediate computer to the second computer in the same
`
`secure connection without requiring the cumbersome exchange of additional keys
`
`to set up a new secure connection between the intermediate computer and the
`
`second computer.” Id., 0237; Goldschlag Decl., ¶51.
`
`
`
`- 11 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`In other words, the Applicant attempted to derive novelty from establishing
`
`a single secure connection between endpoints, rather than establishing separate
`
`secure connections between the intermediate computer and each of the two
`
`endpoints. Indeed, the Examiner allowed the claims of the ’949 patent after the
`
`claims were amended to employ a single “secure connection.” Id., 0081. The
`
`Applicant differentiated the claims from the applied prior art, alleging that the prior
`
`art “merely teaches the use of two tunnels,” and “expressly teaches away from
`
`using a single tunnel” between the two endpoints. Id., 0088-90 (emphasis in
`
`original). The claims of the ’397 patent are substantially similar to those of the
`
`’949 patent, and as discussed in the grounds below, the prior art is replete with
`
`examples of this architecture. Goldschlag Decl., ¶52.
`
`The Examiner did not consider RFC3104 or Grabelsky.
`
`3.
`The ’397 patent is a continuation of the ’949 patent and was originally
`
`allowed following an Examiner proposed amendment, without any rejections being
`
`issued. Ex. 1003, Prosecution History, 0293-0304. As an indication of its similarity
`
`to the claims of the ’949 patent, Applicant filed a Terminal Disclaimer over the
`
`’949 patent before the claims were allowed. Id., 0331-32. After a series of
`
`administrative issues, including abandonment and revival of the application, the
`
`’397 patent finally issued almost four years later in September 2017. ’397 patent,
`
`
`
`- 12 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`Cover. The Examiner cited the same reasons for allowance as cited in the parent
`
`application, the ’949 patent. Prosecution History, 0302.
`
`In the long prosecution of the parent ’949 patent, the ’949 patent was subject
`
`to seven different rejections, two requests for continued examination, and an
`
`appeal brief, before a notice of allowance was eventually received.’949
`
`Prosecution History, 0106, 0132, 0167, 0208, 0269, 0318, 0358, 0382, 0415, 0463.
`
`In fact, more than five and a half years passed from the first rejection of the ’949
`
`patent in 2008 to issuance in 2013.
`
`The claims of the ’949 patent were first rejected as being anticipated by U.S.
`
`Patent Pub. No. 2001/0047487 to Linnakangas et al. (“Linnakangas”). Id., 466.
`
`Applicant argued against Linnakangas by amending the claims and emphasizing
`
`that “an important feature of the invention is that a secure message may be sent
`
`from a first computer to a second computer even when there is an intermediate
`
`computer therebetween that is part of the same secure connection.” Id., 443. The
`
`Examiner, unconvinced, issued a final Action again rejecting the claims as being
`
`anticipated by Linnakangas. Id., 417.
`
`After a request for continued examination and two more Office Actions
`
`rejecting the claims in view of Linnakangas, Applicant filed a notice of appeal and
`
`an appeal brief. In the appeal brief, Applicant continued to argue the “[u]nique
`
`features of the present invention are the secure connection is established all the
`
`
`
`- 13 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`way between the first computer and the second computer via the intermediate
`
`computer.” Id., 237. The Examiner eventually reopened prosecution, replacing
`
`Linnakangas with U.S. Patent Pub. No. 2002/0091921 to Kunzinger, which taught
`
`“end to end data sending via an intermediate gateway using secure tunnels.” Id.,
`
`211.
`
`Two more rejections followed based on Kunzinger. Id., 106, 167. The
`
`Examiner was incorrectly persuaded only after Applicant amended the claims to
`
`require “secure forwarding of a message from a first computer to a second
`
`computer using a secure connection via an intermediate computer.” Id., 81
`
`(underline shows amendment). The patent then issued on January 1, 2013.
`
`But neither the ’949 patent nor the ’397 patent should have issued. And
`
`neither RFC3104 nor Grabelsky were considered during prosecution of the ’397
`
`and ’949 patents. As discussed in detail below, the ’397 patent would never have
`
`been issued in view of these references had they been in front of the Examiner
`
`during prosecution.
`
`Level of Ordinary Skill in the Art
`
`B.
`A person having ordinary skill in the art (POSITA) would have a Bachelor’s
`
`(B.S.) degree in Computer Science, Computer Engineering, Electrical Engineering,
`
`or an equivalent field, as well as at least 2-5 years of academic or industry
`
`experience in the field of Internet security. Goldschlag Decl., ¶¶29-30.
`
`
`
`- 14 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`
`C. Claim Construction
`In an inter partes review, claims are “construed using the same claim
`
`construction standard that would be used to construe the claim in a civil action
`
`under 35 U.S.C. 282(b).” 37 C.F.R. §42.100(b). Claims must be given their
`
`ordinary and customary meaning as understood by one of ordinary skill in the art at
`
`the time of the invention in light of the specification and the prosecution history
`
`pertaining to the patent. Id.; Phillips v. AWH Corp., 415 F.3d 1303, 1312-1313
`
`(Fed. Cir. 2015) (en banc); see also 83 Fed. Reg. 51,340 (Oct. 11, 2018).
`
`“secure connection”
`1.
`Independent claim 1 recites the term “secure connection.” The term “secure
`
`connection” should be construed to encompass “one or more security
`
`associations.”
`
`This is consistent with the use of the term in both the specification and
`
`prosecution history. The specification explains that “[t]he IP security protocols
`
`(IPSec) provides the capability to secure communications between arbitrary hosts,
`
`e.g., across a LAN, across private and public wide area networks (WANs) and
`
`across the internet.” ’397 patent, 1:50-53. The specification further explains that
`
`“[a] security association is a one-way relationship between a sender and a receiver
`
`that offers security services to the traffic carried on it.” Id., 2:16-20. In other
`
`
`
`- 15 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`words, one establishes one or more security associations in order to create a
`
`“secure connection” using IPSec protocols. Goldschlag Decl., ¶¶54-56.
`
`The proposed construction is also consistent with the prosecution history of
`
`the parent ’949 patent. During prosecution, the Applicant specifically equated the
`
`term “security association” to “a secure connection.” ’949 Prosecution History,
`
`0239 (“Linnakangas merely teaches the step of setting up of a secure connection
`
`(security association)”). Moreover, the Applicant expressly admitted that the prior
`
`art “describes the establishment of a security association (which is one type of
`
`secure connection.).” Id., 0240.
`
`Accordingly, the term “secure connection” should be construed to
`
`encompass “one or more security associations.”
`
`“unique identity”
`2.
`The term “unique identity” should be construed as “one or more parameters
`
`that uniquely identify a secure connection.”
`
`Independent claim 1 recites a “unique identity.” The ’397 patent does not
`
`provide a definition of the term “unique identity,” but rather provides only example
`
`embodiments. For example, when employing IPSec, the “unique identity” can be
`
`“one or more SPI [(security parameter index)] values and the other security
`
`parameters contain e.g. the IPsec sequence number(s).” ’397 patent, 7:9-11. Thus,
`
`at a minimum, the proper construction of the recited “unique identity”
`
`
`
`- 16 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`encompasses a combination of multiple parameters related to the secure
`
`connection. Goldschlag Decl., ¶57.
`
`Further, the ’397 patent does not further restrict the parameters that may be
`
`included in the recited “unique identity.” Id., ¶58. The “unique identity” must only
`
`be “unique” in that it can be used to “find[] a destination address of the secure
`
`message,” as recited in claim 1. In other words, the “unique identity” can be used
`
`to uniquely identify the “secure connection” such that it can be used in “sending
`
`the secure message in the secure connection” to its correct destination address. Id.,
`
`¶58.
`
`For these reasons, the Board should construe the term “unique identity” as
`
`“one or more parameters that uniquely identify a secure connection.”
`
` Grounds of Unpatentability VII.
`
`
`A. Ground 1: Claims 1 and 2 are unpatentable under 35 U.S.C. § 103
`as obvious over RFC3104 and Grabelsky.
`
`RFC3104 in view of Grabelsky teaches or suggests every limitation of
`
`claims 1 and 2, as discussed in detail below.
`
`1. Overview of RFC3104
`RFC3104 discloses “mechanisms that enable Realm Specific IP (RSIP) to
`
`handle end-to-end IPsec (IP Security).” Ex. 1004, RFC3104, 1. As Dr. Goldschlag
`
`indicates in his declaration, “RSIP is based on the concept of granting a host from
`
`one addressing realm a presence in another addressing realm by allowing it to use
`
`
`
`- 17 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`resources (e.g., addresses and other routing parameters) from the second
`
`addressing realm.” Goldschlag Decl., ¶61; Ex. 1019, RFC3102, 3. Similar to the
`
`mobility considerations of the ’397 patent, RSIP allows a host the mobility to
`
`move between different networks and bind to different network addresses, for
`
`example “a remote user with a laptop [that] gains access to the Internet, perhaps by
`
`using PPP or DHCP.” RFC3104, 16; Goldschlag Decl., ¶62. RFC3104 integrates
`
`the concepts of RSIP with IPSec protocols and techniques to address security
`
`considerations. Goldschlag Decl., ¶62.
`
`RFC3104 discloses “a first computer and a second computer establishing a
`
`secure connection … via [an] intermediate computer,” as recited in the ’397 patent
`
`claims. Specifically, RFC3104 discloses creating an end-to-end secure connection
`
`between hosts belonging to different address spaces, as shown in the following
`
`diagram:
`
`RFC3104, 3 (annotated).
`
`
`
`RFC3104 explains: “Hosts X [i.e., a second computer] and Y [i.e., a first
`
`computer] belong to different address spaces A and B, respectively, and N is an
`
`
`
`- 18 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`RSIP server [i.e., an intermediate computer]. 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. RFC3104 discloses example applications, such as a “home office” scenario
`
`as well as a “Roadwarrior scenario” in which “a remote user with a laptop gains
`
`access to the Internet” and “[t]he user wants to access its corporation private
`
`network.” Id., 15-16; Goldschlag Decl., ¶64.
`
`In the above model used for purposes of illustration in RFC3104, host X is
`
`an RSIP client, but host Y may be a “legacy IKE and IPsec node” that need not be
`
`RSIP-aware. Id., 3. RFC3104 specifically discusses the scenario in which “RSIP
`
`server N is examining a packet sent by Y, destined for X, for purposes of
`
`illustration. This implies that ‘source’ refers to Y and ‘destination’ refers to Y’s
`
`peer, namely, X’s presence at N.” Id., 3; Goldschlag Decl., ¶65.
`
`RFC3104 further discloses “establishing a secure connection by negotiating
`
`and exchanging keys with one another according to a key exchange protocol via
`
`the intermediate computer.” Specifically, in order for host Y to communicate with
`
`host X, RFC3104 discloses that an IPSec security association (SA) is established
`
`from Y to X: “The RSIP client X and server N must arrive at an SPI value to
`
`denote the incoming IPsec security association from Y to X. Once N and X make
`
`
`
`- 19 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 9,762,397
`sure that the SPI is unique within both of their SPI spaces, X communicates its
`
`value to Y as part of the IPsec security association establishment process, namely,
`
`Quick Mode in IKE [] or manual assignment.” RFC3104, 5.
`
`Once an SA is established, host Y is able to send “send[] the secure message
`
`in the secure connection,” as recited in the ’397 patent claims, to RSIP client X
`
`through RSIP server N: “IPsec packets from Y destined for X arrive at RSIP server
`
`N.” Id. RFC3104 discloses that packets received from Y “are demultiplexed based
`
`on the following minimum tuple of demul