UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`
`
`
`APPLE INC.,
`Petitioner
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner
`____________________
`
`Case IPR2019-00821
`U.S. Patent No. 8,037,302
`____________________
`
`
`
`
`
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 8,037,302
`
`
`
`
`
`
`
`
`
`
`
`
`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. 8,037,302
`
`TABLE OF CONTENTS
`
`
`Introduction ...................................................................................................... 1
`I.
`II. Mandatory Notices (37 C.F.R. § 42.8) ............................................................ 2
`III. Grounds for Standing (37 C.F.R. § 42.104(a)) ................................................ 3
`IV.
`Identification of Challenge (37 C.F.R. § 42.104(b)) ....................................... 3
`A. Statutory grounds for the challenge. ................................................................ 3
`B. Citation of Prior Art ......................................................................................... 4
`V.
`The ’302 Patent ................................................................................................ 6
`A. Overview of the ’302 Patent ............................................................................ 6
`B. Prosecution History of the ’302 Patent and Alleged Novelty .......................11
`C. Level of Ordinary Skill in the Art .................................................................14
`D. Claim Construction ........................................................................................14
`VI. Grounds of Rejection .....................................................................................17
`A. Ground 1: Claims 1-13, and 16 are obvious over Ahonen and Ishiyama .....17
`1. Overview of Ahonen ..................................................................................17
`2. Overview of Combination of Ahonen and Ishiyama .................................21
`3. Ahonen in view of Ishiyama renders claims 1 obvious. ............................27
`4. Ahonen in view of Ishiyama renders claim 2 obvious. ..............................38
`5. Ahonen in view of Ishiyama renders claim 3 obvious. ..............................41
`6. Ahonen in view of Ishiyama renders claim 4 obvious. ..............................41
`7. Ahonen in view of Ishiyama renders claim 5 obvious. ..............................42
`8. Ahonen in view of Ishiyama renders claims 6 obvious. ............................43
`9. Ahonen in view of Ishiyama renders claims 7, 9, 10, and 13 obvious. .....44
`10. Ahonen in view of Ishiyama renders claim 8 obvious. ..............................46
`11. Ahonen in view of Ishiyama renders claim 11 obvious. ............................47
`12. Ahonen in view of Ishiyama renders claim 12 obvious. ............................48
`13. Ahonen in view of Ishiyama renders claim 16 obvious. ............................49
`B. Ground 2: Claims 14-15 are obvious over Ahonen, Ishiyama, and Gupta ...50
`1. Ahonen and Ishiyama in view of Gupta render claims 14 and 15 obvious.
` ....................................................................................................................52
`
`- i -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`VII. Conclusion ....................................................................................................54
`
`
`
`- ii -
`
`

`

`
`
`
`
`
`
`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`
`EXHIBIT LIST
`
`1002
`
`Apple (EX)
`Exhibit # Description
`U.S. Patent No. 8,037,302 to Vaarala et al. (“’302 patent”)
`1001
`Prosecution History of U.S. Patent No. 8,037,302 (“Prosecution
`History”)
`Declaration of David Goldschlag, Ph.D. in Support of Petition for
` Inter Partes Review of U.S. Patent No. 8,037,302 (“Goldschlag
`Decl.”)
`International Patent Pub. No. WO 01/54379 A1 to Ahonen
`(“Ahonen”)
`U.S. Patent No. 6,904,466 to Ishiyama et al. (“Ishiyama”)
`Gupta et al., “Complete Computing,” WWCA '98 Proceedings of
`the Second International Conference on Worldwide Computing
`and Its Applications (March 4-5, 1998)
`RFC2401 – “Security Architecture for the Internet Protocol,” The
`Internet Society (November 1998) (“RFC2401”)
`RFC2409 – “The Internet Key Exchange (IKE)” The Internet
`Society (November 1998) (“RFC2409”)
`Curriculum Vitae of David Goldschlag, Ph.D.
`Zao et al., “A public-key based secure Mobile IP*” Wireless
`Networks, Vol. 5, Issue 5 (1999) (“Zao”)
`Inoue et al., “Secure Mobile IP Using IP Security Primitives,”
`Proceedings of IEEE 6th Workshop on Enabling Technologies:
`Infrastructure for Collaborative Enterprises (June 18-20, 1997)
`(“Inoue”)
`U.S. Patent No. 7,174,018 to Patil et al. (“Patil”)
`Declaration of James L. Mullins (“Mullins Decl.”)
`U.S. Patent No. 6,587,680 to Ala-Laurila et al. (“Ala-Laurila”)
`Curriculum Vitae of James L. Mullins
`K. Townsend, “Understanding VPNs And PPTP,” PC Network
`Advisor, Issue 97 (July 1998) (“Townsend”)
`PCT. Pub. No. WO 03/030488 A1to Vaarala (“’302 PCT
`Publication”)
`
`1003
`
`1004
`1005
`
`1006
`
`1007
`
`1008
`
`1009
`
`1010
`
`1011
`
`1012
`1013
`1014
`1015
`
`1016
`
`1017
`
`- iii -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`
`Apple (EX)
`Exhibit # Description
`Declaration of Sandy Ginoza for IETF (“Ginoza Decl.”)
`1018
`
`
`
`- iv -
`
`

`

`
`
`I.
`
`
`
`
`
`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`
`Introduction
`Apple Inc. petitions for inter partes review of claims 1-16 of United States
`
`Patent No. 8,037,302 (“’302 patent”) to Vaarala et al., titled “Method and System
`
`for Ensuring Secure Forwarding of Messages.” The Petition demonstrates that all
`
`16 claims of the ’302 patent are unpatentable.
`
`The ’302 patent allegedly solved Internet Protocol Security (IPSec)
`
`operability problems for mobile devices. As will be further clarified below, it did
`
`not. Rather, these IPSec problems were well-known and solved long before the
`
`earliest priority date of the ’302 patent. See Ex. 1003, Goldschlag Decl., ¶¶33-38.
`
`IPSec refers to a set of protocols developed in the early 1990s that provides for the
`
`establishment and maintenance of secure communication channels between
`
`devices. IPSec was not developed for mobile devices and operability problems
`
`arose when attempts were made to apply IPSec to mobile devices. Specifically, as
`
`mobile devices roam between networks, their IP addresses change. Id., ¶34. This
`
`presented a problem for IPSec because it relies on having fixed IP addresses for the
`
`endpoints of a connection. Id. Because of this IPSec limitation, a mobile device
`
`needed to renegotiate its connection as it traveled between networks and obtain
`
`new IP addresses, which was inefficient and resulted in connection issues. Id.
`
`The ’302 patent presents a trivial solution to this problem that was already
`
`well-known. The ’302 patent simply retains each secure connection created by a
`
`
`
`- 1 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`mobile device as it travels between networks, and then reuses each respective
`
`connection when the mobile device travels back to a network with a previous
`
`connection. As demonstrated herein, Ahonen—a reference the patent applicant
`
`knew about but did not disclose to the Office—explicitly disclosed this approach
`
`prior to the earliest priority date of the ’302 patent. The dependent claims do not
`
`add any meaningful claim limitations, which are also disclosed by prior art that
`
`existed well before the ’302 patent priority date. For example, Ishiyama and Gupta
`
`disclose well-known claim elements, such as checking whether a connection exists
`
`before using it, and using tunneling protocols like L2TP with VPNs.
`
`Accordingly, there is at least a reasonable likelihood that at least one claim
`
`of the ‘302 patent is unpatentable. As such, Petitioner respectfully requests that the
`
`Board institute trial on the grounds set forth herein and ultimately determine that
`
`all claims of the ’302 patent are invalid.
`
`II. Mandatory Notices (37 C.F.R. § 42.8)
`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 ’310 patent is
`
`involved in the following proceeding that may affect or be affected by a decision in
`
`this proceeding: MPH Technologies Oy v. Apple Inc., Case No. 4:18-cv-05935-
`
`PJH (N.D. Cal.), filed September 27, 2018.
`
`
`
`- 2 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`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 Keyur P. Parikh (Reg. No. 72,807) as its
`
`back-up counsel, all at the address: STERNE, KESSLER, GOLDSTEIN & FOX, 1100
`
`New York Avenue, N.W., Washington, D.C., 20005, phone number (202) 371-
`
`2600 and facsimile (202) 371-2540.
`
`SERVICE INFORMATION: Petitioner consent to electronic service by email at the
`
`email
`
`addresses: mspecht-PTAB@skgf.com,
`
`dblock-PTAB@skgf.com,
`
`kparikh-PTAB@skgf.com and PTAB@sternekessler.com.
`
`III. Grounds for Standing (37 C.F.R. § 42.104(a))
`The undersigned and Apple certify that the ʼ302 patent is available for inter
`
`partes review. Pursuant to 37 C.F.R. § 42.104(a), Petitioner certifies that the ’302
`
`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 ’302
`
`patent on the grounds identified herein.
`
`IV.
`A.
`
`Identification of Challenge (37 C.F.R. § 42.104(b))
`
`Statutory grounds for the challenge.
`
`Petitioner requests review of claims 1-16 on the following grounds:
`
`
`
`GROUND 1: Claims 1-13, and 16 are unpatentable under 35 U.S.C. § 103
`
`as obvious over PCT Patent Publication No. WO 01/54379 to Ahonen (“Ahonen”)
`
`in view of U.S. Patent No. 6,904,466 to Ishiyama et al. (“Ishiyama”).
`
`
`
`- 3 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`GROUND 2: Claims 14 and 15 are unpatentable under 35 U.S.C. § 103 as
`
`obvious over Ahonen and Ishiyama in view of “Complete Computing,” by Gupta
`
`et al (“Gupta”).
`
`B. Citation of Prior Art
`In support of the grounds of unpatentability cited above, Petitioner cites the
`
`following prior art references:
`
`PCT Patent Publication No. WO 01/54379 to Ahonen, titled “A Secure
`
`Communication Method for Mobile IP,” is prior art under at least 35 U.S.C. §
`
`102(e) because it was published on July 26, 2001, before the earliest possible
`
`priority date of the ’302 patent. Ahonen is also prior art under 35 U.S.C. § 102(b)
`
`because Ahonen was published before the ’302 patent’s foreign priority date.1
`
`Ahonen is provided as Exhibit 1004.
`
`U.S. Patent No. 6,904,466 to Ishiyama et al., titled “Mobile Communication
`
`Scheme Without Home Agents for Supporting Communications of Mobile Nodes,”
`
`is prior art under at least 35 U.S.C. § 102(e) because it was filed on May 19, 2000,
`
`
`1 For purposes of 35 U.S.C § 102(b), the relevant date to establish a refer-
`
`ence 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. 8,037,302
`before the earliest possible priority date of the ’302 patent. Ishiyama is provided as
`
`Exhibit 1005.
`
` “Complete Computing,” by Vipul Gupta, Gabriel Montenegro, Jeff
`
`Rulifson, is prior art under at least 35 U.S.C. §§ 102(a) and 102(b) because it was
`
`published on March 4, 1998, which is more than 1 year before the earliest possible
`
`priority date of the ’302 patent. Gupta is provided as Exhibit 1006.
`
`A copy of Gupta is submitted with the declaration of Dr. James L. Mullins,
`
`Ph.D as Attachment 1B. Compare Ex. 1006, Gupta, with Ex. 1013, Mullins Decl.,
`
`Attachment 1B. Gupta was originally published in the proceedings at the Second
`
`International Conference for Worldwide Computing and Its Applications
`
`(“WWCA ’98”) held in Tsukuba, Japan on March 4-5, 1998, as indicated in the
`
`published conference proceedings. Mullins Decl., ¶45, Attachment 1A. As Dr.
`
`Goldschlag testifies from his experience, conferences such as WWCA ’98 were
`
`typically open to the interested public, and Gupta would have been distributed on
`
`March 4, 1998, to attendees of the conference without restriction. Goldschlag
`
`Decl., ¶6.
`
`Dr. Mullins testifies that the WWCA ’98 conference proceedings, including
`
`Gupta, were received at Cornell University Libraries on July 21, 1998. Mullins
`
`Decl., ¶¶40, 41-43, Attachment 1A. Dr. Mullins confirms that there is no
`
`difference between Gupta and the same article found in Attachment 1A. Id., ¶42.
`
`
`
`- 5 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`Dr. Mullins explains that libraries, such as Cornell University Libraries, typically
`
`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, Gupta was publicly available at least by July 1998.
`
`Dr. Mullins also indicates that Gupta was publicly accessible such that
`
`interested individuals, including POSITAs, could have located and obtained it. Id.,
`
`¶¶43-49. For example, Dr. Mullins explains that the conference proceedings that
`
`include Gupta were indexed, and Gupta could be located at least by conference
`
`title and by subject. Id., ¶¶44-46. Searches for Gupta could be performed anywhere
`
`in the world by accessing catalogs such as WorldCat or its predecessor, First
`
`Search, which was available before the earliest priority date of the ’302 patent. Id.,
`
`¶¶19-20, 44-47.
`
`V. The ’302 Patent
`A. Overview of the ’302 Patent
`The ’302 patent generally relates to “a method for ensuring secure
`
`forwarding of a message in telecommunication network,” particularly a network
`
`where at least one of the nodes is a mobile node. Ex. 1001, ’302 patent, 12:15-16;
`
`see also 1:13-16. The “secure forwarding of a message” described in the ’302
`
`patent is IPSec: “IPSec can encrypt and/or authenticate traffic at [an] IP level.”
`
`’302 patent, 1:49. But according to the ’302 patent, IPSec “is designed for a static
`
`
`
`- 6 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`Internet, where the hosts using IPSec are relatively static.” ’302 patent, 3:21-22. In
`
`other words, IPSec is designed for networks where IP addresses are fixed. See
`
`Goldschlag Decl., ¶¶24, 34. “Thus, IPSec does not work well with mobile
`
`devices.” ’302 patent, 3:22-23. The reason for this, according to the ’302 patent, is
`
`because the mobile device must renegotiate its keys every time it changes IP
`
`addresses, which is “expensive” in terms of “latency” and “computation” time. Id.,
`
`3:28-30.
`
`The ’302 patent attempts to solve these problems by re-using the parameters
`
`of previously created secure connections when a mobile device changes networks.
`
`Id., 7:45-53, 10:39-43; see Goldschlag Decl., ¶25. This eliminates the step of
`
`having to renegotiate keys because the mobile device simply reuses the keys that
`
`were previously negotiated. Id. This re-use process is further explained below with
`
`reference to Figure 2:
`
`
`
`- 7 -
`
`
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`
`’302 patent, FIG. 2.
`
`At step 1, “[a] secure connection, preferably an IPSec security association
`
`(SA)” is established between the network address of the mobile terminal and the
`
`home server. See ’302 patent, 10:12-16. A security association or “SA” is “a one-
`
`way relationship between a sender and a receiver that offers security services to the
`
`traffic carried on it.” Id., 2:63-67. If bi-directional communication is required, then
`
`two security associations are established. Id., 2:1-5. The security association,
`
`among other parameters, includes the encryption keys that have been negotiated
`
`between the hosts that are used to encrypt and decrypt traffic. Id., 2:9-19. The ’302
`
`patent uses the terms “secure connection” or “IPSec connection” and “security
`
`association” interchangeably: “IPSec security associations are used as secure
`
`connections.” Id., 7:54-55, 2:1-2 (“[t]he term IPSec connection is used in what
`
`follows in place of an IPSec bundle of one or more security associations SAs”).
`
`The details of the “security associations” between two hosts are stored in a
`
`database located on each of the hosts known as a “IPSec Security Association
`
`Database” or “SADB.” See id., 7:45-53. In order to use the secure connection, each
`
`of the hosts queries their SADB to obtain the details of the secure connections,
`
`such as encryption/decryption keys, and so forth.
`
`Turning back to FIG. 2, IPSec processing works as follows. A message sent
`
`through the IPSec tunnel is marked “IP/IPSec/IP/Data” because the IPSec is a
`
`
`
`- 8 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`tunneling protocol which tunnels IP packets. When the home server, receives
`
`encrypted IPSec messages, it decrypts them, and forwards them to their destination
`
`based upon the destination address specified within the IP packet that is inside of
`
`the IPSec packet. See Goldschlag Decl., ¶29. The ’302 patent explains that packets
`
`from X to the mobile terminal are handled similarly. ’302 patent, 10:26-27. The
`
`packet is first routed to the home server. Then, it is processed via IPSec and
`
`encrypted, “during which an outer IP header is added to the packet and delivered to
`
`the current network(s) (in step 4) the mobile terminal is in.” Id., 10:26-31.
`
`But, as explained above, when the mobile terminal moves to a new network,
`
`it obtains a new address from the visited network, which the ’302 patent refers to
`
`as a “care-of address.” Id., 4:4-5, 4:14-16. As explained above, this would
`
`normally cause the mobile terminal to have to renegotiate its keys—causing
`
`latency and extra computations. Id., 9:36-43. But the alleged invention of the ’302
`
`patent seeks to avoid this by simply having “[t]he mobile terminal… check[]
`
`whether an SA (or more precisely, a pair of SA bundles) SA already exists between
`
`the new care-of address and the home server address.” Id., 10:42-45. In other
`
`words, whether there was already a security association that was previously created
`
`between the mobile terminal and host X. This check is done by querying the
`
`mobile terminal’s SADB. Id., 10:39-43. If a previously created SA already exists,
`
`then “this SA is registered to be the actual SA to be used” for further
`
`
`
`- 9 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`communications. Id., 10:55-56. If a previously-created SA does not exist between
`
`the “new care-of address and the home server, a[] [new] SA setup occurs….” Id.,
`
`10:66-11:3.
`
`The ’302 patent refers to the process of the mobile host selecting the correct
`
`secure connection to use as “registration.” Id., 10:51-56. Specifically, “[w]hen the
`
`first terminal moves from one address to another address, a secure connection,
`
`whose endpoints are the new address of the first terminal and the address of the
`
`other terminal, is registered to be at least one of the active connections.” Id., 7:16-
`
`20. This process is further described with reference to steps 5 and 6 of FIG. 2,
`
`shown below:
`
`’302 patent, FIG. 2.
`
`
`
`
`
`- 10 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`The ’302 patent explains that “Step 5 is a registration request from the
`
`mobile host to the home server to register the new address and step 6 is a
`
`registration reply back to the mobile terminal.” ’302 patent, 10:63-65. The
`
`registration request is what signifies to the home server that a different secure
`
`connection should be considered the “active” connection. The reply is confirmation
`
`that the home server received the registration request, but “[i]t is also within the
`
`scope of the invention to only use a Registration Request message …., but not
`
`using a Registration Reply message.” Id., 11: 27-30. And although the registration
`
`requests are “preferably the Mobile IP Registration Request and Registration Reply
`
`messages,…other registration formats may also be used.” Id., 11:24-28.
`
`Prosecution History of the ’302 Patent and Alleged Novelty
`
`B.
`The prosecution of the ’302 patent was neither simple nor short. In fact, the
`
`Examiner determined eight times the claims were not allowable. And it took seven
`
`years and three rounds of examination before the application that became the ’302
`
`patent was finally allowed by the Examiner. But the prosecution could have been
`
`much simpler. As shown by this Petition, had the Office been aware of the Ahonen
`
`reference, the claims would never have been allowed. This did not occur, however.
`
`Applicant was aware of Ahonen reference and its materiality to the ’302 patent, but
`
`never disclosed it to the Office.
`
`
`
`- 11 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`Shortly after the filing of the application that led to the ’302 patent, the
`
`applicant submitted the only Information Disclosure Statement in the record. Ex.
`
`1002, Prosecution History, 0119-0120. In that disclosure statement, the Applicant
`
`stated “Applicant knows of no information in addition to the references cited in
`
`the International Search Report that would be material to the patentability of
`
`the claimed invention.” Id. Presumably, Applicant was referring to the
`
`International Search Report of the PCT application to which the ’302 patent claims
`
`priority. And indeed, this Search Report lists Ahonen. Ex. 1017, ’302 PCT
`
`Publication, 30. But despite acknowledging that it was aware of the references
`
`cited in that Report, which includes Ahonen, Applicant never cited Ahonen to the
`
`Office, and further, did not submit the search report either. Yet, under its duty of
`
`candor with the Office, Applicant was required to submit this information. See
`
`M.P.E.P. 2001.05(b).
`
`Without the benefit of Ahonen, the Examiner instead located other prior-art
`
`references during the prosecution of the ’302 patent. And during prosecution, the
`
`Examiner first applied U.S. Patent No. 6,587,680 (“’680 patent”) to Ala-Laurila,
`
`which is a reference that describes reusing of security associations when a mobile
`
`terminal moves between access points. Ex. 1014, Ala-Laurila, 8:6-9. Initially, the
`
`Examiner contended that Ala-Laurila completely anticipated the claims, but after
`
`several rounds of amendments by the Patent Applicant, the Examiner ultimately
`
`
`
`- 12 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`withdrew Ala-Laurila when the Applicant added the limitations that the “second
`
`secure connection” extends between a new address of the first terminal and the
`
`original address of the second terminal. Prosecution History, 0246. This was
`
`because, according to Applicant, Ala-Laurila taught that when a mobile terminal
`
`moves it never changes addresses. Prosecution History, 0243-0255.
`
`Next, after withdrawing Ala-Laurila, the Examiner issued a new rejection
`
`based on U.S. Pat. No. 6,091,951 to Sturnilio in view of U.S. Pat. No. 7,165,173 to
`
`Herle. According to the Examiner, Sturnilio described a system that established
`
`connections between a first and second terminal, the first terminal changing
`
`addresses, and creating a new connection between the new address of the first
`
`terminal and the second terminal. Prosecution History, 0259-0260. The only
`
`element that Sturnilio did not teach was that such connections were secure, for
`
`which the Examiner relied on the teachings of Herle. In response, through a series
`
`of claim amendments over several Office Actions, the Applicant ultimately
`
`amended the claims to recite “when the second secure connection already exists,
`
`the second terminal registering the already established second secure connection as
`
`being the active connection without having to reestablish the second secure
`
`connection.” Prosecution History, 0297. But the examiner still rejected the claims.
`
`It was not until the Applicant filed an Appeal Brief that the ’302 patent was
`
`allowed. In the Appeal Brief, the Applicant argued that Sturnilio does not disclose
`
`
`
`- 13 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`two distinct connections because the mobile terminal of Sturnilio never actually
`
`changes network addresses, and thus Sturnilio does not disclose the registering of
`
`the second secure connection as “active” when it already exists. Ultimately, the
`
`Examiner was persuaded by these arguments, and allowed the application, stating
`
`that “the prior art does not teach the second terminal registering the already
`
`established second secure connection in combination with the other limitations of
`
`the claim.” Prosecution History, 0375. But as explained further below, this was not
`
`true, as Ahonen in combination with Ishiyama discloses all of the limitations of the
`
`claims, including the register limitations
`
`C. Level of Ordinary Skill in the Art
`Based on the disclosure of the ’302 patent, a person of ordinary skill in the
`
`art (”POSITA”) would have a B.S. degree in Computer Science, Electrical
`
`Engineering, or an equivalent field, as well as at least 3-5 years of academic or
`
`industry experience in network security, or comparable industry experience.
`
`Goldschlag Dec., ¶22.
`
`D. 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 a POSITA at the time of the
`
`
`
`- 14 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`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. Below, Petitioner provides a construction for
`
`the terms “a first secure connection”/ “a second secure connection.” As to the
`
`remaining terms, for the purposes of this proceeding, those claims should be given
`
`their plain and ordinary meaning, as understood by a POSITA and consistent with
`
`the disclosure.
`
`1. “a first secure connection”/ “a second secure connection”
`
`The terms “establishing a first secure connection”/ “establishing a second
`
`secure connection,” as recited in claim 1, should be construed to respectively
`
`include “establishing one or more first security associations” and “establishing one
`
`or more second security associations.” Goldschlag Decl., ¶¶40-43.
`
`This is consistent with both the claims and the specification. For example,
`
`claim 3, depends from claim 1, and recites “establishing the first secure connection
`
`by using IPSec protocols.” Because of this dependency, “establishing the first
`
`secure connection” of claim 1 must be broad enough to include “establishing the
`
`first secure connection by using IPSec protocols.” See Alcon Research, Ltd. v.
`
`Apotex Inc., 687 F.3d 1362, 1367 (Fed. Cir. 2012) (citing Intamin Ltd. V. Magnetar
`
`Techs., Corp., 483 F.3d 1328, 1335 (Fed. Cir. 2007) (“An independent claim
`
`impliedly embraces more subject matter than its narrower dependent claim.”). The
`
`
`
`- 15 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`specification explains that “[t]he IP security protocols (IPSec) provides the
`
`capability to secure communications across a LAN, across private and public wide
`
`area networks (WANs) and across the internet.” ’302 patent, 1:38-40. And that the
`
`“[t]he secure connections are preferably established by forming Security
`
`Associations (SAs) using the IPSec protocols” Id., 7:39-41. In other words, an
`
`IPSec connection is created using one or more security associations. Thus, one
`
`establishes one or more security associations in order to create a “secure
`
`connection” using the IPSec protocols. See Goldschlag Decl., ¶41.
`
`The ’302 patent specification also repeatedly uses the terms “security
`
`association” and “secure connection” interchangeably. For example, “IPSec
`
`security associations are used as secure connections.” ’302 patent, 7:54-55; see
`
`also id., 2:1-2 (“IPSec connection is used in what follows in place of an IPSec
`
`bundle of one or more security associations SAs.”); Id., 8:45-46 (“an IPSec
`
`security association is used instead of the IP-IP tunneling.”).
`
`Accordingly, the terms “establishing a first secure connection”/ “establishing
`
`a second secure connection” should be construed broadly to enough to respectively
`
`include “establishing one or more first security associations” and “establishing one
`
`or more second security associations.”
`
`
`
`- 16 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`
`VI. Grounds of Rejection
`A. Ground 1: Claims 1-13, and 16 are obvious over Ahonen and Ishiyama
`Ahonen discloses each and every limitation of claims 1-13, and 16 except
`
`Ahonen suggests, but does not explicitly disclose, that the mobile terminal
`
`“check[s] whether the second secure connection already exists.” While this
`
`limitation would have been obvious in view of Ahonen alone, Ishiyama explicitly
`
`discloses that when a mobile terminal moves to a visitor network, the mobile
`
`terminal searches security association database for security association extending
`
`between a care-of-address in the visitor network and the destination address. As
`
`explained in further detail below, it would have been obvious to a POSITA at the
`
`time of the ’302 patent’s invention to combine Ahonen and Ishiyama.
`
`1. Overview of Ahonen
`
`Ahonen generally relates to “a secure communication method for allowing a
`
`mobile host to communicate with a correspondence host over a Virtual Private
`
`Network.” Ex. 1004, Ahonen, 0006:1-5. As Ahonen explains, “[t]here is an ever
`
`increasing demand for mobility in communications systems.” Id., 0003:10. But this
`
`need must be balanced with security considerations. Id., 0003:11-13. Like the ’302
`
`patent, Ahonen explains that one way to solve this problem is through the use of
`
`VPNs, and more specifically IPSec. Id., 0003:13-17. But as both the ’302 patent
`
`and Ahonen explain, “[i]n the IPsec model the end points of the secure connection
`
`
`
`- 17 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`are identified by their IP addresses.” Id., 0003:21-22. And this creates a problem
`
`for mobile users that roam between networks. Id., 0003:22-26. Specifically, “[t]he
`
`main problem is that the IP address allocated to the roaming mobile user is likely
`
`to change dynamically as the user moves between access networks.” Id., 0003:22-
`
`26. And just like the ’302 patent, Ahonen explains that when this occurs, the
`
`mobile hosts IP address changes, and in such a case it is “difficult to reuse the pre-
`
`existing security associations (of IPsec)….” Id., 0003:26-29. Worse yet, the mobile
`
`host will likely have to reauthenticate, which will result in “increased signaling”
`
`and “degrad[ed] performance.” Id., 0003:30-31.
`
`To solve this problem, Ahonen proposes the same solution as the ’302
`
`patent—reusing security associations as a mobile host travels between networks.
`
`But Ahonen’s solution was published long before the ’302 patent’s earliest priority
`
`date. Specifically, Ahonen discloses “negotiating one or more Security
`
`Associations [i.e., secure connections] between the mobile host [i.e., a first
`
`terminal] and a correspondent host [i.e., a second terminal] of a Virtual Private
`
`Network.” Id., 0004:7-8. Ahonen further explains that these multiple secure
`
`connections are pre-established: “[e]mbodiments of the present invention reduce
`
`the amount of security related messaging during on-the-fly IP address changes, as
`
`the SAs needed to provide for secure communication between the mobile host and
`
`the correspondent host pre-exist.” Id., 0004:30-32 (emphasis added). The result of
`
`
`
`- 18 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 8,037,302
`this, is that multiple “SAs (phase 1 and phase 2)” are pre-established between the
`
`mobile host (i.e.,