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

`

`
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`TABLE OF CONTENTS
`
`
`I.
`
`II.
`
`III.
`
`
` The ’949 Patent ................................................................................................ 8 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 .......................................................... 7
`
`A. Overview of the ’949 Patent ....................................................................... 8
`1. Brief Overview of IPSec and SSL ..................................................... 9
`2. The ’949 patent focused on employing standard IPSec protocols to
`establish a single secure connection. .......................................................12
`3. The Examiner did not consider RFC3104, Grabelsky, or Wagner
`during prosecution. ..................................................................................15
`B. Level of Ordinary Skill in the Art ............................................................17
`C. Claim Construction ...................................................................................17
`1.
`“secure connection” .........................................................................17
`2.
`“unique identity [of the secure connection]” ...................................19
`
`A. Ground 1: Claims 1, 2, 4-7, 9, 11-14, 20-21, and 27-29 are unpatentable
`under 35 U.S.C. § 103 as obvious over RFC3104 and Grabelsky. ..........20
`1. Overview of RFC3104 .....................................................................20
`2. Overview of the Combination of RFC3104 and Grabelsky ............23
`3. The combination of RFC3104 and Grabelsky renders claim 1
`obvious. ...................................................................................................29
`4. The combination of RFC3104 and Grabelsky renders claim 2
`obvious. ...................................................................................................44
`5. The combination of RFC3104 and Grabelsky renders claim 4
`obvious. ...................................................................................................45
`6. The combination of RFC3104 and Grabelsky renders claim 5
`obvious. ...................................................................................................48
`
` Grounds of Unpatentability ...........................................................................20 V.
`
`
`
`- i -
`
`

`

`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`7. The combination of RFC3104 and Grabelsky renders claim 6
`obvious. ...................................................................................................48
`8. The combination of RFC3104 and Grabelsky renders claim 7
`obvious. ...................................................................................................49
`9. The combination of RFC3104 and Grabelsky renders claim 9
`obvious. ...................................................................................................52
`10. The combination of RFC3104 and Grabelsky renders claim 11
`obvious. ...................................................................................................54
`11. The combination of RFC3104 and Grabelsky renders claim 12
`obvious. ...................................................................................................56
`12. The combination of RFC3104 and Grabelsky renders claim 13
`obvious. ...................................................................................................58
`13. The combination of RFC3104 and Grabelsky renders claim 14
`obvious. ...................................................................................................58
`14. The combination of RFC3104 and Grabelsky renders claim 20
`obvious. ...................................................................................................59
`15. The combination of RFC3104 and Grabelsky renders claim 21
`obvious. ...................................................................................................60
`16. The combination of RFC3104 and Grabelsky renders claim 27
`obvious. ...................................................................................................61
`17. The combination of RFC3104 and Grabelsky renders claim 28
`obvious. ...................................................................................................63
`18. The combination of RFC3104 and Grabelsky renders claim 29
`obvious. ...................................................................................................64
`B. Ground 2: Claim 3 is unpatentable under 35 U.S.C. § 103 as obvious over
`RFC3104, Grabelsky, and Wagner. ..........................................................65
`1. Overview of Wagner ........................................................................65
`2. The combination of RFC3104, Grabelsky, and Wagner renders
`claim 3 obvious. ......................................................................................66
`
` Conclusion. ....................................................................................................71 VI.
`
`
`
`
`
`
`
`
`- ii -
`
`

`

`EXHIBIT LIST
`
`Exhibit No.
`
`Description
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`1001
`
`1002
`
`1003
`
`1004
`
`1005
`
`1006
`
`1007
`
`1008
`
`1009
`
`1010
`
`1011
`
`1012
`
`1013
`
`1014
`
`1015
`
`1016
`
`1017
`
`U.S. Patent No. 8,346,949 B2 to Vaarala et al., issued Jan. 1, 2013
`
`Declaration of David Goldschlag, Ph.D. (“Goldschlag Decl.”)
`
`Prosecution History of U.S. Patent No. 8,346,949 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
`
`Wagner et al., Analysis of the SSL 3.0 Protocol, USENIX (Nov.
`1996)
`
`Declaration of Ms. Sandy Ginoza
`
`Curriculum Vitae of David Goldschlag, Ph.D.
`
`Declaration of James L. Mullins Ph.D.
`
`Curriculum Vitae of James L. Mullins
`
`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)
`
`RFC2246 - The TLS Protocol Version 1.0 (Jan. 1999)
`
`RFC2401 - Security Architecture for the Internet Protocol (Nov.
`1998)
`
`RFC2402 - IP Authentication Header (Nov. 1998)
`
`RFC2406 - IP Encapsulating Security Payload (ESP) (Nov. 1998)
`
`
`
`- iii -
`
`

`

`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`Exhibit No.
`
`Description
`
`1018
`
`1019
`
`1020
`
`RFC2409 - The Internet Key Exchange (IKE) (Nov. 1998)
`
`RFC3102 - Realm Specific IP: Framework (Oct. 2001)
`
`Zhang et al., “A Multu-Layer IPsec Protocol,” (Aug. 2000)
`
`
`
`
`
`
`
`
`
`- iv -
`
`

`

`Apple Inc. petitions for inter partes review of claims 1-7, 9, 11-14, 20-21,
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`and 27-29 of United States Patent No. 8,346,949 to Vaarala et al. (Ex. 1001, “the
`
`’949 patent”), titled “Method and System for Sending a Message Through a Secure
`
`Connection.” The Petition demonstrates that all 29 claims of the ’949 patent are
`
`unpatentable.
`
`The ’949 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 ’949 patent were well-known and solved long before the
`
`earliest priority date of the ’949 patent. Ex. 1002, Goldschlag Decl., ¶50. In
`
`particular, the ’949 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 ’949 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 and
`
`Ilnicki prior to the earliest priority date of the ’949 patent. Additionally, Grabelsky
`
`and Wagner explain other well-known and simple elements of the claims that
`
`would have been known to a POSITA, such as data packet formats, use of
`
`translation tables, and use of Secure Sockets Layer (SSL).
`
`
`
`- 1 -
`
`

`

`Accordingly, there is at least a reasonable likelihood that at least one claim
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`of the ’949 patent is unpatentable, as shown herein. Therefore, Petitioner
`
`respectfully requests that the Board Institute trial on the grounds set forth herein
`
`and ultimately determine that all claims of the ’949 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 ’949 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. 9,762,397 (IPR2019-00825); 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.
`
`
`
`- 2 -
`
`

`

`Service Information: Petitioner consents to electronic service by email at
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`the email addresses: mspecht-PTAB@sternekessler.com, dblock-
`
`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 ’949 patent is available for inter
`
`partes review. Pursuant to 37 C.F.R. § 42.104(a), Petitioner certifies that the ’949
`
`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 ’949
`
`patent on the grounds identified herein.
`
`III.
`
`
`Identification of Challenge (37 C.F.R. § 42.104(b))
`A. Citation of Prior Art
`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
`
`
`1 Apple does not acquiesce that the ’949 patent is entitled to a priority date
`
`based on the foreign filed application.
`
`
`
`- 3 -
`
`

`

`U.S.C. §§ 102(a) and 102(b) because it was published at least as of October 2001,
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`more than one year prior to the effective U.S. filing date of the ’949 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
`
`
`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 -
`
`

`

`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`regular practice of the RFC Editor to make and keep the RFC records.” Id., ¶¶9-10.
`
`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, 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 under at least pre-AIA 35
`
`
`
`- 5 -
`
`

`

`U.S.C. § 102(e) because it was filed on March 17, 1999, prior to the earliest
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`possible priority date of the ’949 patent.
`
`“Analysis of the SSL 3.0 Protocol,” by David Wagner and Bruce Schneier
`
`(Ex. 1006, “Wagner”) is prior art under at least pre-AIA 35 U.S.C. §§ 102(a) and
`
`102(b) because it was published more than one year prior to the earliest possible
`
`priority date of the ’949 patent.
`
`A copy of Wagner is submitted with the declaration of Dr. James L. Mullins,
`
`Ph.D, as Attachment 1B. Compare Ex. 1006 with Ex. 1009, Mullins Decl.,
`
`Attachment 1B. Wagner was originally published in the Proceedings of the Second
`
`USENIX Workshop on Electronic Commerce, held in Oakland, California on
`
`November 18-21, 1996, as indicated in the published conference proceedings.
`
`Mullins Decl., ¶¶38-42, Attachment 1A. As Dr. Goldschlag testifies from his
`
`experience, USENIX Workshops such as this were typically open to the interested
`
`public, and Wagner would have been distributed on November 18, 1996, to
`
`attendees of the conference without restriction. Goldschlag Decl., ¶9.
`
`Dr. Mullins testifies that the Second USENIX Workshop on Electronic
`
`Commerce conference proceedings, including Wagner, were received at the
`
`University of Rochester Libraries on May 19, 2000. Mullins Decl., ¶¶39, 43,
`
`Attachment 1A. Dr. Mullins confirms that there is no difference between Ex. 1007
`
`(Wagner) and the same article found in Attachment 1A. Id., ¶42. Dr. Mullins
`
`
`
`- 6 -
`
`

`

`explains that libraries, such as the University of Rochester Libraries, typically
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`make conference proceeding publications available very soon after receipt,
`
`“normally within a few days of receipt or (at most) within a few weeks of receipt.”
`
`Id., ¶¶31, 33. Thus, Wagner was publicly available at least by May 2000.
`
`Dr. Mullins also indicates that Wagner was publicly accessible such that
`
`interested individuals, including POSITAs, could locate and obtain it. Id., ¶¶43-49.
`
`For example, Dr. Mullins explains that the conference proceedings that include
`
`Wagner were indexed, and Wagner could be located at least by conference title and
`
`by subject. Id., ¶¶44-46. Searches for Wagner could be performed anywhere in the
`
`world by accessing, for example, WorldCat or its predecessor, First Search, which
`
`was available before the earliest priority date of the ’949 patent. Id., ¶¶19-20, 26,
`
`44-46. Wagner was also cited by other references prior to the priority date of the
`
`’949 patent, providing additional support for the public availability of Wagner. Id.,
`
`¶¶47-48.
`
`Accordingly, RFC3104 was published and available no later than May 2000.
`
`Statutory Grounds for the Challenge
`
`B.
`Petitioner requests review of claims 1-7, 9, 11-14, 20-21, and 27-29 on the
`
`following two grounds:
`
`Ground 1: Claims 1, 2, 4-7, 9, 11-14, 20-21, and 27-29 are unpatentable
`
`under 35 U.S.C. § 103 as obvious over RFC3104 and Grabelsky; and
`
`
`
`- 7 -
`
`

`

`Ground 2: Claim 3 is unpatentable under 35 U.S.C. § 103 as obvious over
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`RFC3104, Grabelsky, and Wagner.
`
` The ’949 Patent IV.
`
`
`A. Overview of the ’949 Patent
`The ’949 patent is directed to general techniques for “secure forwarding of a
`
`message from a first computer to a second computer.” ’949 patent, Abstract. The
`
`’949 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:27-29. The ’949 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:9-26.
`
`The ’949 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:43-50, 4:27-28. Thus, when a host is mobile, the patent alleges that IPSec
`
`provides no mechanism to alter parameters of the secure connection. Id., 4:28-31.
`
`Because of this, the patent alleges that existing solutions employing IPSec “either
`
`employ extra tunnelling, causing extra packet size overhead, or use separate
`
`
`
`- 8 -
`
`

`

`tunnels, causing potential security problems in the intermediate host(s) that
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`terminate such tunnels.” Id., 6:10-13. However, numerous solutions already existed
`
`in the prior art that addressed these alleged problems in substantially the same way
`
`as the ’949 patent.
`
`Brief Overview of IPSec and SSL
`
`1.
`The specification of the ’949 patent focuses on implementation of IPSec
`
`protocols to establish secure connections between devices. See, e.g., ’949 patent,
`
`6:64-67. Additionally, dependent claim 3 recites “making use of SSL or TLS
`
`protocols.”3 Id., 22:44-46.
`
`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:43-45; Goldschlag Decl., ¶35.
`
`“[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.” Id.; ’949 patent, 1:46-
`
`50.
`
`
`3 Of note, the ’949 patent does not mention “SSL” or “TLS” outside of claim
`
`3, as discussed further in Ground 2.
`
`
`
`- 9 -
`
`

`

`A key concept of IPSec is a security association (SA), and the ’949 patent
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`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.” ’949 patent,
`
`2:7-12. “[I]f a secure two way relationship is needed, then two security
`
`associations are required.” Id., 2:11-12. The ’949 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.”
`
`’949 patent, 2:28-38; Goldschlag Decl., ¶¶37-38.4
`
`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).” ’949 patent, 1:64-
`
`2:3; Goldschlag Decl., ¶36. IPSec services further support two modes: “[t]ransport
`
`
`4 Emphasis added unless otherwise indicated in this Petition.
`
`
`
`- 10 -
`
`

`

`mode” and “tunnel mode.” ’949 patent, 3:1-4; Goldschlag Decl., ¶39. “Transport
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`mode provides protection primarily for upper layer protocols and extends to the
`
`payload of an IP packet,” while “[t]unnel mode provides protection to the entire IP
`
`packet.” ’949 patent, 3:3-12. The ’949 patent makes use of these IPSec protocols
`
`and modes in the same way as the prior art. Goldschlag Decl., ¶40.
`
`SSL is a protocol that is “is intended to provide a practical, application-
`
`layer, widely applicable connection-oriented mechanism for Internet client/server
`
`communications security.” Wagner, 0002. Around the time of the ’949 patent, SSL
`
`had “become a de facto standard for cryptographic protection of Web http traffic.”
`
`Id.; Goldschlag Decl., ¶44. SSL and its successor, TLS, are often used as an
`
`alternative to IPSec, although the protocol standards may be used in conjunction
`
`with one another. Goldschlag Decl., ¶44.
`
`“SSL is divided into two layers, with each layer using services provided by a
`
`lower layer and providing functionality to higher layers. The SSL record layer
`
`provides confidentiality, authenticity, and replay protection over a connection-
`
`oriented reliable transport protocol such as TCP. Layered above the record layer is
`
`the SSL handshake protocol, a key-exchange protocol which initializes and
`
`synchronizes cryptographic state at the two endpoints. After the key-exchange
`
`protocol completes, sensitive application data can be sent via the SSL record
`
`layer.” Wagner, 0002; Goldschlag Decl., ¶45.
`
`
`
`- 11 -
`
`

`

`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`The ’949 patent focused on employing standard IPSec
`protocols to establish a single secure connection.
`
`2.
`
`The ’949 patent purports to “develop a method for forwarding secure
`
`messages between two computers, especially, via an intermediate computer.” ’949
`
`patent, 6:17-20. The ’949 patent illustrates an example telecommunication network
`
`in Figure 1:
`
`’949 patent, FIG. 1 (annotated).
`
`
`
`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.” Id., 9:57-61.
`
`Server 2 acts as the intermediate computer between client computer 1 and security
`
`gateway 3.
`
`
`
`- 12 -
`
`

`

`The ’949 patent describes that “an IPSec connection is formed between the
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`client computer 1 (the first computer) and the security gateway 3 (the second
`
`computer).” Id., 10:32-34. 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:34-39. 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:8-10.
`
`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:45-49. A message sent to the intermediate computer (e.g.,
`
`server 2) includes “a unique identity and a destination address.” Id., 6:33-35. This
`
`unique identity and destination address “are used to find an address to the second
`
`computer” (e.g., security gateway 3). Id., 6:36-38. 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
`
`
`
`- 13 -
`
`

`

`destination address of the second computer. Id., 6:38-41. The message is then
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`forwarded from the intermediate computer (e.g., server 2) to the second computer
`
`(e.g., security gateway 3). Id., 6:41-42.
`
`During prosecution, 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. 1003, 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.
`
`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
`
`
`
`- 14 -
`
`

`

`using a single tunnel” between the two endpoints. Id., 0088-0090 (emphasis in
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`original). But, as discussed in the grounds below, the prior art is replete with
`
`examples of this architecture.
`
`3.
`
`The Examiner did not consider RFC3104, Grabelsky, or
`Wagner during prosecution.
`
`In its long prosecution, 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. Ex. 1003, 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., 0466.
`
`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., 0443. The
`
`Examiner, unconvinced, issued a final Action again rejecting the claims as being
`
`anticipated by Linnakangas. Id., 0417.
`
`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
`
`
`
`- 15 -
`
`

`

`an appeal brief. In the appeal brief, Applicant continued to argue the “[u]nique
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`features of the present invention are the secure connection is established all the
`
`way between the first computer and the second computer via the intermediate
`
`computer.” Id., 0237. 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.,
`
`0211.
`
`Two more rejections followed based on Kunzinger. Id., 0106, 0167. 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., 0081
`
`(underline shows amendment). The patent then issued on January 1, 2013.5
`
`But the ’949 patent should never have issued in view of Applicant’s minor
`
`amendment to the claims. And none of RFC3104, Grabelsky, or Wagner was
`
`considered during prosecution of the ’949 patent. As discussed in detail below, the
`
`
`5 Four years after the patent finally issued, Applicant requested a Certificate
`
`of Correction to correct typographical errors in independent claim 1. Id., 0001-
`
`0008. Those corrections are reflected in this Petition.
`
`
`
`- 16 -
`
`

`

`’949 patent would never have been issued in view of these references had they
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`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 had 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., ¶¶31-32.
`
`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. 51340.
`
`“secure connection”
`1.
`Each of claims 1, 15, 27, and 28 recite the term “secure connection.” The
`
`term “secure connection” should be construed to encompass “one or more security
`
`associations.”
`
`
`
`- 17 -
`
`

`

`This is consistent with the use of the term in both the specification and
`
`Case IPR2019-00822
`U.S. Pat. No. 8,346,949
`
`
`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.” ’949 patent, 1:43-46. The specification