Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper 7
`Entered: November 6, 2019
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`APPLE INC.,
`Petitioner,
`
`
`
`v.
`
`
`
`MPH TECHNOLOGIES OY,
`Patent Owner.
`
`Case IPR2019-00823
`Patent 9,712,494 B2
`
`__________________________
`
`Before SALLY C. MEDLEY, KAMRAN JIVANI, and
`JOHN D. HAMANN, Administrative Patent Judges.
`
`HAMANN, Administrative Patent Judge.
`
`
`
`
`DECISION
`Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`Tel: 571-272-7822
`
`Paper 7
`Entered: November 6, 2019
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`APPLE INC.,
`Petitioner,
`
`
`
`v.
`
`
`
`MPH TECHNOLOGIES OY,
`Patent Owner.
`
`Case IPR2019-00823
`Patent 9,712,494 B2
`
`__________________________
`
`Before SALLY C. MEDLEY, KAMRAN JIVANI, and
`JOHN D. HAMANN, Administrative Patent Judges.
`
`HAMANN, Administrative Patent Judge.
`
`
`
`
`DECISION
`Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`I.
`
`INTRODUCTION
`
`Apple Inc. (“Petitioner”) filed a Petition (Paper 2, “Pet.”) requesting
`
`an inter partes review of claims 1–11 of U.S. Patent No. 9,712,494 B2
`
`(Ex. 1001, “the ’494 patent”) pursuant to 35 U.S.C. § 311. MPH
`
`Technologies Oy (“Patent Owner”) filed a Patent Owner Preliminary
`
`Response (Paper 6, “Prelim. Resp.”).
`
`We have authority to determine whether to institute an inter partes
`
`review under 35 U.S.C. § 314 and 37 C.F.R. § 42.4(a). An inter partes
`
`review may be instituted if “the information presented in the petition filed
`
`under section 311 and any response filed under section 313 shows that there
`
`is a reasonable likelihood that the petitioner would prevail with respect to at
`
`least 1 of the claims challenged in the petition.” 35 U.S.C. § 314(a). On
`
`April 24, 2018, the Supreme Court held that a decision to institute under
`
`35 U.S.C. § 314 may not institute on fewer than all claims challenged in the
`
`Petition. SAS Inst., Inc. v. Iancu, 138 S. Ct. 1348, 1359–60 (2018).
`
`Upon consideration of the Petition and the Preliminary Response, we
`
`determine that the information presented shows there is a reasonable
`
`likelihood that Petitioner would prevail in establishing the unpatentability of
`
`at least one challenged claim of the ’494 patent. Accordingly, we institute
`
`inter partes review on all of the challenged claims based on all of the
`
`grounds identified in the Petition.
`
`A. Related Matter
`
`The parties identify MPH Techs. Oy v. Apple Inc., Case No. 4:18-cv-
`
`05935-PJH, in the U.S. District Court for the Northern District of California,
`
`as a matter that may affect or would be affected by a decision in this
`
`proceeding. Pet. 2; Paper 4, 1. The parties also identify as related matters
`
`2
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`the following additional inter partes reviews: IPR2019-00822,
`
`IPR2019-00824, IPR2019-00825, and IPR2019-00826. Pet. 2; Paper 4, 1.
`
`B. The Challenged Patent (Ex. 1001)
`
`The ’494 patent relates to the “secure forwarding of a message from a
`
`first computer to a second computer via an intermediate computer in a
`
`telecommunication network.” Ex. 1001, 6:38–41. According to the ’494
`
`patent, “[a]n essential idea of [its] invention is to use the standard [Internet
`
`Protocol (‘IP’) Security (‘IPSec’)] protocol . . . between the intermediate
`
`computer and the second computer and an ‘enhanced IPSec protocol’
`
`between the first computer and the intermediate computer.” Id. at 7:38–41,
`
`1:54. More specifically, the ’494 patent states that “[t]he advantage of [its]
`
`invention is that [a] logical IPSec connection shared by the first and the
`
`second computer can be enhanced by the first and the intermediate computer
`
`without involvement of the second computer.” Id. at 10:38–41. The ’494
`
`patent adds: “[i]n particular[,] the so-called ‘ingress filtering’ performed by
`
`some routers [(e.g., the second computer)] does not pose any problems when
`
`translations of addresses are used.” Id. at 10:41–44.
`
`
`
`Figure 1, shown below, “illustrates an example of a
`
`telecommunication network of the invention” of the ’494 patent. Id. at
`
`9:55–56.
`
`3
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`
`
`
`
`Figure 1 shows an example of a telecommunication network in
`
`accordance with the invention of the ’494 patent. Id. at 10:4–5. As
`
`illustrated, the network comprises: (i) a first computer (client computer 1)
`
`that is served by (ii) an intermediate computer (server 2), and (iii) host
`
`computer 4 that is served by (iv) a second computer (security gateway 3).
`
`Id. at 10:4–9. Security gateway 3 “supports the standard IPSec protocol,”
`
`while client computer 1 and server 2 support an enhanced IPSec protocol.
`
`Id. at 10:9–12. The ’494 patent discloses that the first computer (i.e., client
`
`computer 1) in Figure 1 is a mobile terminal. Id. at 11:5–7, 11:13–14.
`
`
`
`“In the example of F[igure] 1, an IPSec connection is formed between
`
`. . . client computer 1 (the first computer) and . . . security gateway 3 (the
`
`second computer).” Id. at 10:46–48. The ’494 patent discloses that
`
`“[m]essages to be sent to . . . host terminal 4 from . . . client computer 1 are
`
`first sent to . . . server 2, wherein an IPSec translation[, inter alia,] . . . takes
`
`place.” Id. at 10:60–62. Put differently, “[w]hen the intermediate computer
`
`4
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`receives the packet sent . . ., it performs an address and [Security Parameters
`
`Index (‘SPI’)] translation, ensuring that the security gateway (host 3 of
`
`F[igure] 1) can accept the packet.” Id. at 12:1–4, 2:40–41. The ’494 patent
`
`states that “translation[s can be] . . . performed[, for example,] by means of a
`
`translation table stored at the intermediate computer[,with t]he outer IP
`
`header address fields and/or the SPI-values [being] changed by the
`
`intermediate computer so that the message can be forwarded to the second
`
`computer.” Id. at 7:46–50.
`
`
`
`According to the ’494 patent, “[m]ost of the packet is secured using
`
`IPSec, . . . [but] the intermediate computer . . . is able to use the outer IP
`
`addresses and the incoming SPI value to determine how to modify the outer
`
`address and the SPI to suite the second computer, which is the next
`
`destination.” Id. at 12:1–11. “[T]he confidentiality of the packets is not
`
`compromised, . . . [because t]he intermediate computer does not know the
`
`cryptographic keys used to encrypt and/or authenticate the packets, and can
`
`thus not reveal their contents,” according to the ’494 patent. Id. at 10:26–37.
`
`After translation, “the message can be sent to . . . security gateway 3, which
`
`sends the message further in plain text to . . . host terminal 4.” Id. at 10:60–
`
`64.
`
`C. The Challenged Claims
`
`Petitioner challenges claims 1–11 of the ’494 patent, of which claim 1
`
`is the sole independent claim. Claim 1 is illustrative of the challenged
`
`claims and is reproduced below:
`
`An intermediate computer for secure forwarding of
`1.
`messages in a telecommunication network, comprising:
`
`an intermediate computer configured to connect to a
`telecommunication network;
`
`5
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`the intermediate computer configured to be assigned with
`
`a first network address in the telecommunication network;
`
`the intermediate computer configured to receive from a
`mobile computer a secure message sent to the first network
`address having an encrypted data payload of a message and a
`unique identity, the data payload encrypted with a cryptographic
`key derived from a key exchange protocol;
`
`the intermediate computer configured to read the unique
`identity from the secure message sent to the first network
`address; and
`to access a
`
`the
`intermediate computer configured
`translation table, to find a destination address from the translation
`table using the unique identity, and
`
`to securely forward the encrypted data payload to the
`destination address using a network address of the intermediate
`computer as a source address of a forwarded message containing
`the encrypted data payload wherein the intermediate computer
`does not have the cryptographic key to decrypt the encrypted data
`payload.
`
`Ex. 1001, 22:40–65.
`
`D. Asserted Grounds of Unpatentability
`
`
`
`Petitioner asserts the following grounds of unpatentability:
`
`Claims Challenged 35 U.S.C. §1
`
`Basis
`
`1–5 and 8–11
`
`§ 103(a)
`
`Request for Comments 3104
`(“RFC3104”)2 and Grabelsky3
`
`
`1 The Leahy-Smith America Invents Act (“AIA”) included revisions to
`35 U.S.C. § 103 that became effective on March 16, 2013. Because the ’494
`patent issued from an application having an effective filing date before
`March 16, 2013, we apply the pre-AIA version of the statutory basis for
`unpatentability.
`2 G. Montenegro & M. Borella, RSIP Support for End-to-end IPsec, Request
`for Comments 3104, The Internet Society (Oct. 2001) (“RFC3104”) (Ex.
`1004).
`3 U.S. Patent No. 7,032,242 B1 (issued Apr. 18, 2006) (Ex. 1006).
`
`6
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`Claims Challenged 35 U.S.C. §1
`
`Basis
`
`6–7
`
`§ 103(a)
`
`RFC3104, Grabelsky, and Wagner4
`
`Pet. 7–8, 20–64. Petitioner submits the Declaration of David Goldschlag,
`
`Ph.D. (Ex. 1002) in support of its arguments.
`
`II. LEVEL OF ORDINARY SKILL IN THE ART
`
`To determine whether an invention would have been obvious at the
`
`time it was made, we consider the level of ordinary skill in the pertinent art
`
`at the time of the invention. Graham v. John Deere Co., 383 U.S. 1,
`
`17 (1966). In assessing the level of ordinary skill in the art, various factors
`
`may be considered, including the “type of problems encountered in the art;
`
`prior art solutions to those problems; rapidity with which innovations are
`
`made; sophistication of the technology; and educational level of active
`
`workers in the field.” In re GPAC, Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995)
`
`(quoting Custom Accessories, Inc. v. Jeffrey-Allan Indus., Inc., 807 F.2d
`
`955, 962 (Fed. Cir. 1986)). “[O]ne or more factors may predominate.” Id.
`
`Petitioner argues that one of ordinary skill in the art at the time of the
`
`invention of the ’494 patent 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.” Pet. 17 (citing Ex. 1002 ¶¶ 31–
`
`32).
`
`Patent Owner does not identify a level of skill one would have had at
`
`the time of the invention of the ’494 patent. For purposes of this Decision
`
`
`4 David Wagner & Bruce Schneier, Analysis of the SSL 3.0 Protocol, Proc.
`2d USENIX Workshop on Elec. Com. (Nov. 1996) (“Wagner”) (Ex. 1007).
`
`7
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`on Institution, and based on the current record, we adopt Petitioner’s
`
`assessment of the level of skill in the art because it is consistent with the
`
`’494 patent and the asserted prior art, and we apply it in our obviousness
`
`evaluation below.
`
`III. CLAIM CONSTRUCTION
`
`Because the Petition was filed after November 13, 2018, we construe
`
`the challenged claims by applying “the standard used in federal courts, in
`
`other words, the claim construction standard that would be used to construe
`
`the claim in a civil action under 35 U.S.C. [§] 282(b), which is articulated in
`
`Phillips [v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc)].”5 Under
`
`Phillips, the words of a claim are generally given their “ordinary and
`
`customary meaning,” which is the meaning they would have to a person of
`
`ordinary skill in the art at the time of the invention, in light of the
`
`specification and prosecution history. See Phillips, 415 F.3d at 1312–13.
`
`Petitioner identifies the claim term “unique identity” for our
`
`construction, whereas Patent Owner identifies the term “mobile computer.”
`
`Pet. 17–20, Prelim. Resp. 4–6.
`
`A. Unique Identity
`
`
`
`Petitioner argues that “unique identity” means “one or more
`
`parameters that uniquely identify a secure connection.” Pet. 18. Patent
`
`Owner does not provide a construction for this term, but states that it
`
`“disagrees with claim constructions used or implied in the Petition for
`
`various claim terms.” Prelim. Resp. 4.
`
`
`5 Changes to the Claim Construction Standard for Interpreting Claims in
`Trial Proceedings Before the Patent Trial and Appeal Board, 83 Fed. Reg.
`51,340, 51,343–44 (Oct. 11, 2018) (to be codified at 37 C.F.R. pt. 42).
`
`8
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`
`
`At this stage of the proceeding, Patent Owner does not argue that
`
`RFC3104 or Grabelsky fails to disclose this term and, therefore, this term is
`
`not in controversy. See generally Prelim. Resp. Furthermore, we have
`
`reviewed Petitioner’s showing for the combination of RFC3104 and
`
`Grabelsky as it relates to the plain and ordinary meaning of this term and
`
`find the showing sufficient for purposes of institution.
`
`
`
`Accordingly, for our purposes on institution, we conclude that no
`
`express claim construction of the term “unique identity” is necessary. See
`
`Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co., 868 F.3d 1013,
`
`1017 (Fed. Cir. 2017) (quoting Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`
`200 F.3d 795, 803 (Fed. Cir. 1999)) (“[W]e need only construe terms ‘that
`
`are in controversy, and only to the extent necessary to resolve the
`
`controversy.’”).
`
`B. Mobile Computer
`
`Patent Owner argues that “the term ‘mobile computer,’ as recited in
`
`the claims, should be construed to require a computer that is capable of
`
`moving from one network to another while maintaining a connection.”
`
`Prelim. Resp. 6. Patent Owner argues that the ’494 states that “the term
`
`mobility and mobile terminal does not only mean physical mobility, instead
`
`the term mobility is in the first hand meant moving from one network to
`
`another, which can be performed by a physically fixed terminal as well.”
`
`Id. at 5 (quoting Ex. 1001, 4:34–38).
`
`Patent Owner argues that “[t]he very next sentence in the ’494
`
`[p]atent differentiates the term ‘mobile’ from static connections[, and] . . .
`
`explains that ‘[t]he problem with standard IPSec is thus that it has been
`
`designed for static connections.’” Id. (quoting Ex. 1001, 4:39–40). Patent
`
`9
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`Owner argues that “[o]ther portions of the [S]pecification [also] support
`
`construing the claim term ‘mobile computer,’” as Patent Owner proposes.
`
`Id. Namely, Patent Owner argues that the ’494 patent (i) “describ[es a] prior
`
`art method that ‘provides mobility for the connection’ but incurs various
`
`problems,” and (ii) “explain[s] that ‘[e]specially, the object of this invention
`
`is to forward secure messages in a way that enables changes to be made in
`
`the secure connection.’” Id. (quoting Ex. 1001, 5:16–22, 6:32–34)
`
`(emphasis added).
`
`
`
`To begin, we focus on the first part of Patent Owner’s proposed
`
`construction, and we agree with Patent Owner that the ’494 patent teaches
`
`that mobility “mean[s] moving from one network to another.” Ex. 1001,
`
`4:34–37. The ’494 patent reiterates this concept: “The mobile terminal is
`
`mobile in the sense that it changes its network point of attachment
`
`frequently.” Id. at 4:50–52. The manner in which Petitioner relies on the
`
`prior art is consistent with this meaning. See Section V(C), infra. Thus, we
`
`need not determine, as to this part of Patent Owner’s proposed construction,
`
`whether “a computer that is capable of moving from one network to
`
`another” differs from the plain meaning of “mobile computer,” as this is not
`
`in controversy. See, e.g., Nidec, 868 F.3d at 1017.
`
`
`
`As to the portion of Patent Owner’s proposed construction reciting,
`
`“while maintaining a connection,” we conclude that Patent Owner does not
`
`provide sufficient justification for importing this limitation from the
`
`Specification into this term. See Superguide Corp. v. DirecTV Enterprises,
`
`Inc., 358 F.3d 870, 875 (Fed. Cir. 2004) (“[I]t is important not to import into
`
`a claim limitations that are not a part of the claim.”). Rather, the ’494
`
`patent’s Specification clearly describes the concept of a mobile terminal and
`
`10
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`provides additional disclosed features to address maintaining a connection in
`
`view of the terminal’s mobility. E.g., Ex. 1001, 4:34–38 (describing
`
`mobility), 7:56–8:10 (sending a signaling request to change addresses).
`
`
`
`We also note that Patent Owner does not address the impact, if any, of
`
`its proposed construction on dependent claim 9, which recites that claim 1’s
`
`“intermediate computer [also] is configured to modify the translation table
`
`entry address fields in response to a signaling message sent from the mobile
`
`computer when the mobile computer changes its address such that the
`
`intermediate computer can know that the address of the mobile computer is
`
`changed.” Ex. 1001, 24:7–13. The additional claimed feature of claim 9 at
`
`least suggests that this feature is not present in claim 1. Nor should this
`
`feature be imported into a construction for “mobile computer.” See
`
`Superguide Corp., 358 F.3d at 875. Accordingly, given the record before us
`
`at this stage of the proceeding, we decline to adopt Patent Owner’s proposed
`
`construction of this term.
`
`This conclusion does not preclude the parties from arguing for
`
`proposed constructions during trial. A final determination as to claim
`
`construction will be made at the close of the proceeding, after any hearing,
`
`based on all the evidence of record. The parties are expected to assert all of
`
`their claim construction arguments and evidence during trial, as permitted by
`
`our Rules.
`
`IV. PRINCIPLES OF LAW
`
`A claim is unpatentable under 35 U.S.C. § 103(a) if the differences
`
`between the claimed subject matter and the prior art are such that the subject
`
`matter, as a whole, would have been obvious at the time of the invention to a
`
`person having ordinary skill in the art. KSR Int’l Co. v. Teleflex, Inc., 550
`
`11
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`U.S. 398, 406 (2007). The question of obviousness is resolved on the basis
`
`of underlying factual determinations, including: (1) the scope and content of
`
`the prior art; (2) any differences between the claimed subject matter and the
`
`prior art; (3) the level of ordinary skill in the art; and (4) objective evidence
`
`of non-obviousness, if present.6 See Graham, 383 U.S. at 17–18. When
`
`evaluating a claim for obviousness, we also must “determine whether there
`
`was an apparent reason to combine the known elements in the fashion
`
`claimed by the patent at issue.” KSR, 550 U.S. at 418 (citing In re Kahn,
`
`441 F.3d 977, 988 (Fed. Cir. 2006)).
`
`V. ALLEGED OBVIOUSNESS OVER RFC3104 AND GRABELSKY
`
`Petitioner argues that the combination of RFC3104 and Grabelsky
`
`renders claims 1–5 and 8–11 of the ’494 patent obvious under 35 U.S.C.
`
`§ 103(a). Pet. 20–59. Below we discuss independent claim 1, as Patent
`
`Owner’s Preliminary Response does not address separately any of the other
`
`challenged claims for this asserted ground. For the reasons that follow, we
`
`determine that Petitioner establishes a reasonable likelihood that it would
`
`prevail in showing that claim 1 would have been obvious to one of ordinary
`
`skill in the art in view of RFC3104 and Grabelsky.
`
`A. Summary of RFC3104
`
`
`
`RFC3104 “proposes mechanisms to handle,” and “specifies RSIP
`
`extensions to enable,” end-to-end IPSec. Ex. 1004, 1–2. Figure 1, shown
`
`below, illustrates a “Model” topology, in accordance with RFC3104’s
`
`teachings. Id. at 2.
`
`
`6 Patent Owner does not present arguments or evidence of such objective
`evidence of non-obviousness. See generally Prelim. Resp.
`
`12
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`
`
`
`
`RFC3104 provides the above illustrated “Model” topology “[f]or
`
`clarity” in discussing its teachings. Id. As shown, “[h]osts X and Y belong
`
`to different address spaces A and B, respectively, and N is an [intermediate]
`
`RSIP server.” Id. at 3. RFC3104 teaches that “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.” Id.
`
`
`
`RFC3104 enables “RSIP client X to initiate . . . IP[S]ec sessions to a
`
`legacy . . . IP[S]ec node Y.” Id. at 3. To that end, RFC3104 teaches that
`
`“RSIP client X and server N must arrive at an SPI value to denote the
`
`incoming IP[S]ec security association [(“SA”)] from Y to X.” Id. at 5.
`
`RFC3104 adds: “Once N and X make sure that the SPI is unique within
`
`both of their SPI spaces, X communicates its value to Y as part of the
`
`IP[S]ec [SA] . . . establishment process.” Id. According to RFC3104,
`
`“[t]his ensures that Y sends IP[S]ec packets . . . to X via address Nb using
`
`the negotiated SPI.” Id. In such a scenario, “IP[S]ec packets from Y
`
`destined for X arrive at RSIP server N.” Id. “RSIP server N . . . examin[es
`
`the] packet[s] sent by Y, destined for X[, which] . . . implies that ‘source’
`
`refers to Y and ‘destination’ refers to Y’s peer, namely, X’s presence at N.”
`
`Id. at 3. N demultiplexes each of the IPSec packets “based on the following
`
`minimum tuple of demultiplexing fields:” protocol, SPI, and destination IP
`
`address. Id. at 5. RFC3104 teaches that “[i]f N is able to find a matching
`
`13
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`mapping, it tunnels the packet to X according to the tunneling mode in
`
`effect.” Id. Otherwise, RFC3104 teaches that “N . . . MUST discard the
`
`packet.” Id.
`
`B. Summary of Grabelsky
`
`
`
`Grabelsky relates to allowing IPSec “to be used with distributed
`
`network address translation . . . by mapping a local . . . [IP] address of a
`
`given local network device and a IP[S]ec . . . [SPI] associated with an
`
`inbound IP[S]sec [SA] . . . that terminates at the local network device.”
`
`Ex. 1006, code (57). “A router allocates locally unique security values that
`
`are used as the IP[S]ec SPIs.” Id. Figure 21, shown below, “is a block
`
`diagram illustrating a SPI-to-internal network address table layout.” Id. at
`
`6:13–14.
`
`
`
`
`
`Figure 21, shown above, illustrates “a SPI-to-internal network address
`
`table,” in accordance with Grabelsky’s teachings. Id. at 27:56–57.
`
`Grabelsky teaches that “a network address for [a] first network device is
`
`stored with . . . one or more locally unique security values in a table [(e.g.,
`
`the table of Figure 21)] associated with [a] second network device.” Id. at
`
`27:21–24, 27:56–58. Grabelsky teaches that “[t]he table is used to maintain
`
`14
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`a mapping between a network device and a locally unique security value for
`
`distributed network address translation with security.” Id. at 27:24–27.
`
`
`
`In accordance with Grabelsky’s teachings, for incoming packets using
`
`IPSec, the router (which routes data packets to another external computer
`
`network) maintains a mapping between local IP addresses of network
`
`devices and SPI values. Id. at 6:34–35, 32:32–34. Grabelsky teaches that
`
`when an IPSec packet arrives on the router, the router examines a SPI value
`
`in the IPSec packet’s outermost header, which is typically visible. Id. at
`
`32:35–39. “The SPI value in the IP[S]ec header is used to determine a local
`
`IP address of a destination network device,” according to Grabelsky’s
`
`teachings. Id. at 32:39–41.
`
`C. Challenged Claim 1
`
`
`
`Petitioner relies on RFC3104 and Grabelsky for teaching claim 1’s
`
`limitations. Pet. 28–50. For the reasons that follow, we determine, based on
`
`the current record, and for purposes of institution, that the combination of
`
`RFC3104 and Grabelsky renders claim 1 of the ’494 patent obvious.
`
`1. Undisputed Limitations
`
`a. Intermediate Computer for Secure Forwarding
`
`
`
`Petitioner argues that RFC3104 discloses “[a]n intermediate computer
`
`for secure forwarding of messages in a telecommunication network,” as
`
`recited in claim 1’s preamble. Id. at 28–30. More specifically, Petitioner
`
`argues that RFC3104 discloses “an RSIP server N (‘intermediate computer’)
`
`forwarding a message (e.g., data packets) sent from a host Y (‘mobile
`
`computer’) to a host X (‘destination’). Id. at 28–29 (citing Ex. 1004, 2;
`
`Ex. 1002 ¶ 83). Petitioner argues that “[t]he interconnected computer
`
`configuration allowing host Y to communicate with host X via RSIP server
`
`15
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`N represents a ‘telecommunication network’ as recited in the claims.” Id. at
`
`29 (citing Ex. 1002 ¶ 84). Petitioner also argues that “[a]n IPSec [SA] . . . is
`
`established from Y to X.” Id. (citing Ex. 1004, 5). According to Petitioner,
`
`“[o]nce an SA is established, host Y is able to securely send messages to
`
`RSIP client X, forwarded through RSIP server N.” Id. at 30 (citing
`
`Ex. 1004, 5; Ex. 1002 ¶ 85).
`
`b. Connect to a Telecommunication Network
`
`
`
`Petitioner argues that RFC3104 discloses “an intermediate computer
`
`configured to connect to a telecommunication network,” as recited in claim
`
`1. Id. at 30. More specifically, Petitioner argues that “the mechanisms
`
`described in RFC3104 are used . . . within telecommunications networks, for
`
`example, private networks and public networks such as the ‘Internet.’” Id.
`
`(citing Ex. 1004, 3; Ex. 1002 ¶ 86).
`
`c. Assigned with a First Network Address
`
`
`
`Petitioner argues that RFC3104 discloses that “the intermediate
`
`computer [is] configured to be assigned with a first network address in the
`
`telecommunication network,” as recited in claim 1. Id. at 30–31. More
`
`specifically, Petitioner argues that “RFC3104 discloses that ‘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.” Id. at 30 (citing Ex. 1004, 3).
`
`16
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`d. Receive a Secure Message7
`
`
`
`Petitioner argues that RFC3104 discloses that “the intermediate
`
`computer [is] configured to receive . . . a secure message sent to the first
`
`network address having an encrypted data payload of a message and a
`
`unique identity, the data payload encrypted with a cryptographic key derived
`
`from a key exchange protocol,” as recited in claim 1. Id. at 31–43. More
`
`specifically, Petitioner argues that RFC3104 discloses that an IPSec SA is
`
`established from Y to X. Id. at 32 (citing Ex. 1004, 5; Ex. 1002 ¶ 89). To
`
`that end, Petitioner argues that “RFC3104 specifically discloses that ‘Y
`
`sends IP[S]ec packets (protocols 51 and 50 for AH and ESP, respectively) []
`
`to X via address Nb,’ and Dr. Goldschlag explains that an IPSec packet is ‘a
`
`secure message’ because the packet is secured in accordance with IPSec
`
`protocols.” Id. (quoting Ex. 1004, 5; citing Ex. 1002 ¶ 90). Petitioner
`
`argues that server N sends the packet (with an address of Na) to host X, and
`
`that both Na and Nb are “network address[es]” of server N. Id.
`
`
`
`In addition, Petitioner argues that one of ordinary skill in the art
`
`“would have understood that an IPSec packet arriving at server N sent from
`
`host Y would include a data payload, which is the primary information
`
`IPSec is designed to protect,” and “that the data payload of the packet sent
`
`from Y to X would be encrypted before being sent from Y.” Id. at 35 (citing
`
`Ex. 1017, 8; Ex. 1002 ¶¶ 96–97); see also id. at 36 (citing Ex. 1002 ¶¶ 99–
`
`101) (arguing that one of ordinary skill in the art “would have understood
`
`that in accordance with IPSec standards, the data payload of the packet
`
`
`7 As we discuss below, Patent Owner disputes that the intermediate
`computer receives the secure message “from a mobile computer.” See infra
`Section V(C)(3).
`
`17
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`would be encrypted in order to protect confidentiality of the data”).
`
`According to Petitioner, RFC3104 teaches that “[t]he IPSec SA from Y to X
`
`is established through use of an Internet Key Exchange (IKE) protocol,
`
`‘namely, Quick Mode in IKE.’” Id. at 36 (quoting Ex. 1004, 5). Petitioner
`
`argues that one of ordinary skill in the art “would have understood that the
`
`use of ‘Quick Mode in IKE’ involves exchange of keying information
`
`(between X and Y in this case), e.g., Diffie-Hellman key information, used
`
`to derive ‘cryptographic key[s].’” Id. (citing Ex. 1002 ¶ 98 (citing Ex. 1018,
`
`16–19)); see also id. (citing Ex. 1004, 3–7) (arguing that “RFC3104
`
`provides further details of IKE support and handling for RSIP”).
`
`
`
`Lastly, Petitioner argues that the combination of RFC3104 and
`
`Grabelsky teaches that the secure message has a unique identity. Id. at 37.
`
`More specifically, Petitioner argues that the message’s “SPI value, the set of
`
`‘demultiplexing fields,’ and the packet headers [(i.e., the IP header and
`
`IPSec protocol header)], each provides a ‘unique identity.’” E.g., id. (citing
`
`Ex. 1002 ¶ 102); see also id. at 37–43 (citing Ex. 1004, 5; Ex. 1006, 20:49–
`
`50, 20:63–66, 21:33–37, 22:17–18, 23:5–9, 24:5–8, 24:21–28, Figs. 15–18;
`
`Ex. 1002 ¶¶ 103–106, 108–109, 112–113) (arguing that the message has a
`
`unique identity).
`
`e. Read the Unique Identity
`
`
`
`Petitioner argues that RFC3104 discloses that “the intermediate
`
`computer [is] configured to read the unique identity from the secure message
`
`sent to the first network address,” as recited in claim 1. Id. at 44. More
`
`specifically, Petitioner argues that RFC3104 discloses a “‘unique identity’ in
`
`the form of packet headers (i.e., the IP header and IPSec protocol header) of
`
`a packet received by RSIP server N from host Y, which contain a set of
`
`18
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`‘demultiplexing fields.’” Id. (citing Ex. 1004, 5). According to Petitioner,
`
`“RFC3104 further discloses that the set of ‘demultiplexing fields’ is read by
`
`RSIP server N (the ‘intermediate computer’).” Id. (citing Ex. 1002 ¶ 114).
`
`In particular, Petitioner argues that RFC3104 discloses that in using the
`
`demultiplexing fields, “[i]f N is able to find a matching mapping, it tunnels
`
`the packet to X according to the tunneling mode in effect.” Id. (quoting
`
`Ex. 1004, 5; Ex. 1002 ¶ 114). Petitioner argues that one of ordinary skill in
`
`the art “would have understood that in order for RSIP server N to search for
`
`a ‘matching mapping,’ server N would need to read the values of the set of
`
`‘demultiplexing fields.’” Id. (citing Ex. 1002 ¶ 114).
`
`f. Access a Translation Table
`
`
`
`Petitioner argues that the combination of RFC3104 and Grabelsky
`
`teaches that “the intermediate computer [is] configured to access a
`
`translation table, to find a destination address from the translation table
`
`using the unique identity,” as recited in claim 1. Id. at 45–46. More
`
`specifically, Petitioner argues that “RFC3104 discloses that packets arriving
`
`at RSIP server N from host Y include a ‘minimum tuple of demultiplexing
`
`fields,’ which are part of the ‘unique identity.’” Id. at 45 (citing Ex. 1004,
`
`5). Petitioner argues that RFC3104 discloses “[u]sing these fields, ‘[i]f N is
`
`able to find a matching mapping, it tunnels the packet to X according to the
`
`tunneling mode in effect.’” Id. (quoting Ex. 1004, 5; citing Ex. 1002 ¶ 115).
`
`
`
`As to Grabelsky, Petitioner argues that Grabelsky teaches the use of
`
`translation tables for mapping. Id. (citing Ex. 1006, Fig. 21). More
`
`specifically, Petitioner argues that Grabelsky teaches “[f]or incoming
`
`packets using IP[S]ec, the router 26 . . . maintains a mapping (F[igure] 21)
`
`between local IP addresses of network devices . . . and SPI values.” Id. at
`
`19
`
`
`
`IPR2019-00823
`Patent 9,712,494 B2
`
`45–46 (quoting Ex. 1006, 32:32–34). Petitioner argues that Grabelsky
`
`teaches that when an IPSec packet arrives at router 26, router 26 examines a
`
`SPI value in the IP[S]ec packet’s outermost header, which is typically
`
`visible. Id. at 46 (citing Ex. 1006, 32:35–39). Grabelsky teaches that “[t]he
`
`SPI value in the IP[S]ec header is used to determine a local IP 54 address of
`
`a destination network device.” Id. (quoting Ex. 1006, 32:39–41).
`
`
`
`Petitioner argues that one of ordinary skill in the art “would have been
`
`motivated to seek out Grabelsky for viable implementation details for the
`
`mapping mechanism at RSIP server N in RFC3104.” Id. (citing Ex. 1002
`
`¶ 118). “RFC3104 already discloses a ‘mapping’ of the ‘minimum tuple of
`
`demultiplexing fields’ to a destination (e.g., the destination address of RSIP
`
`client X),” according to Petitioner. Id. (citing Ex. 1004, 5; Ex. 1002 ¶ 118).
`
`Petitioner argues thus “[t]he combin
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
