Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper 9
`Entered: June 30, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`
`Before MICHAEL P. TIERNEY, KARL D. EASTHOM, and
`STEPHEN C. SIU, Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`I. INTRODUCTION
`A. Background
`Petitioner, Apple Inc., filed a Petition (Paper 1, “Pet.”) requesting an
`inter partes review of claims 1–11, 14–25, and 28–30 (the “challenged
`claims”) of U.S. Patent No. 8,504,696 B2 (Ex. 1001, “the ’696 patent”).
`Patent Owner, VirnetX Inc., filed a Preliminary Response. Paper 6 (“Prelim.
`Resp.”).
`We have authority to determine whether to institute an inter partes
`review. 35 U.S.C. § 314(b); 37 C.F.R. § 42.4(a). The standard for
`instituting an inter partes review is set forth in 35 U.S.C. § 314(a), which
`provides that an inter partes review may not be instituted “unless the
`Director determines . . . there is a reasonable likelihood that the petitioner
`would prevail with respect to at least 1 of the claims challenged in the
`petition.”
`After considering the Petition and Preliminary Response, we
`determine that Petitioner has established a reasonable likelihood of
`prevailing in showing the unpatentability of at least one of the challenged
`claims. Accordingly, we institute inter partes review.
`B. Related Matters
`Petitioner indicates that the ’696 patent “has not been asserted in
`litigation or the subject of other IPR proceedings.” Pet. 2. Petitioner
`concurrently filed a petition challenging the same claims in the ’696 patent
`in IPR2016-00332. Id. at 4. Petition and Patent Owner provide listings of
`district court actions, other inter partes review, and inter partes
`reexamination proceedings challenging related patents. See Pet. 3–4, Paper
`5, 2–10; see also VirnetX, Inc. v. Cisco Systems, Inc., 767 F.3d 1308, 1317–
`
`2
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`19 (Fed. Cir. 2014) (addressing ancestor VirnetX patents). Some of these
`related cases are discussed further below as necessary.
`C. The Asserted Grounds of Unpatentability
`Petitioner contends, under 35 U.S.C. § 103, that claims 1–11, 14–25,
`and 28–30 of the ’696 patent are unpatentable based on the combination of
`Beser1 and RFC 2401.2 Pet. iii, 28. Petitioner also relies on the Declaration
`of Roberto Tamassia (Ex. 1005) and the Declaration of the RFC Publisher
`for the Internet Engineering Task Force, an Organized Activity of the
`Internet Society (Ex. 1060), signed by Sandy Ginoza.
`D. The ’696 Patent
`The ’696 patent describes secure methods for communicating over the
`Internet. Ex. 1001, Abstract, 10:3–8. Specifically, the ’696 patent describes
`“the automatic creation of a virtual private network (VPN) in response to a
`domain-name server look-up function.” Id. at 39:23–25. This automatic
`creation employs a modified Domain Name Server, which may include a
`conventional Domain Name Server (DNS) and a DNS proxy (id. at 40:20–
`40:22):
`
`Conventional Domain Name Servers (DNSs) provide a
`look-up function that returns the IP address of a requested
`computer or host. For example, when a computer user types in
`the web name “Yahoo.com,” the user’s web browser transmits a
`request to a DNS, which converts the name into a four-part IP
`address that is returned to the user’s browser and then used by
`the browser to contact the destination web site.
`
`Id. at 39:26–32.
`
`1 U.S. Patent No. 6,496,867 B1 (Ex. 1007).
`2 S. Kent and R. Atkinson, Security Architecture for the Internet Protocol,
`Request for Comments: 2401, BBN Corp., November 1998 (Ex. 1008).
`
`3
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`The DNS proxy of the modified DNS server intercepts all DNS
`lookup requests, determines whether the user has requested access to a
`secure site (using for example, a domain name extension or an internal
`table of secure sites), and if so, whether the user has sufficient security
`privileges to access the requested site. Id. at 40:26–35. If the user has
`requested access to a secure site to which it has insufficient security
`privileges, the DNS proxy returns a “‘host unknown’” error to the
`user. Id. at 40:49–53. If the user has requested access to a secure site
`to which it has sufficient security privileges, the DNS proxy requests a
`gatekeeper to create a VPN between the user’s computer and the
`secure target site. Id. at 40:31–42. The DNS proxy then returns to the
`user the resolved address passed to it by the gatekeeper, which need
`not be the actual address of the destination computer. Id. at 40:43–44.
`The VPN is “preferably implemented using the IP address
`‘hopping’ features,” (i.e., changing IP addresses based upon an agreed
`upon algorithm) described elsewhere in the ’696 patent, “such that the
`true identity of the two nodes cannot be determined even if packets
`during the communication are intercepted.” Id. at 39:4–8.
`E. Illustrative Challenged Claim 1
`Independent claims 1 and 16 recite the same limitations respectively
`in system and method format. Compare Ex. 1001, 56:8–23, with id. at 57:1–
`14. All other challenged claims depend from claims 1 or 16. Claim 1,
`illustrative of the challenged claims, follows:
`
`
`
`
`
`4
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`1. A system for connecting a first network device and a
`
`second network device, the system including one or more
`servers configured to:
`
`
`
`intercept, from the first network device, a request to look
`up an internet protocol (IP) address of the second network
`device based on a domain name associated with the second
`network device;
`
`
`
`
`
`determine, in response to the request, whether the second
`network device is available for a secure communications
`service; and
`
`initiate a virtual private network communication link
`between the first network device and the second network device
`based on a determination that the second network device is
`available for the secure communications service, wherein the
`secure communications service uses the virtual private network
`communication link.
`Ex. 1001, 56:8–23.
`F. Alleged Redundancy with IPR2016-00332
`
`Patent Owner argues the present case is redundant with the petition
`filed in IPR2016-00332 (“’332 IPR”), and the Board should deny institution
`on that basis. Prelim. Resp. 34–38. Patent Owner contends that “redundant
`grounds place a significant burden on the Board and the patent owner, and
`cause unnecessary delay that jeopardizes meeting the statutory deadline for
`final written decisions.” Id. at 35 (citation omitted).
`Patent Owner explains that one of the grounds in the ’332 IPR
`“simply substitutes Beser with Aventail.” Id. at 35. Although the grounds
`asserted here are similar to those asserted in the ’332 IPR, they are not the
`same. Furthermore, Beser and Aventail have been involved in several recent
`proceedings between the two parties. See, e.g., Apple Inc. v. VirnetX Inc.,
`
`5
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`IPR2014-00237 (PTAB May 11, 2015) (Paper No. 41) (final written
`decision “’237 FWD”, or generally, “’237 IPR”); Apple Inc. v. VirnetX Inc.,
`Case IPR2015-00811 (PTAB Sept. 11, 2015) (Paper 8); Apple Inc. v.
`VirnetX Inc., Case IPR2015-00812 (PTAB Sept. 11, 2015) (Paper 8); Apple
`Inc. v. VirnetX Inc., IPR2015-00870 (PTAB Oct. 1, 2015) (Paper No. 8);
`Apple Inc. v. VirnetX Inc., IPR2015-00871 (PTAB Oct. 1, 2015) (Paper No.
`8). Aventail also has been involved in litigation between the parties and
`prosecution at the Office. See IPR2015-00871, Paper 8, 8, 19–20 n.6 (citing
`Reexamination Control. No. 95/002, 269 and discussing a similar
`redundancy issue).
`Under the specific circumstances involved at this juncture, the Beser-
`based and Aventail-based grounds would not place a significant burden on
`the parties or the Board. Accordingly, Patent Owner has not shown a
`sufficient reason to deny this Petition or the petition in IPR2016-00332, and
`we decline to exercise our discretion to deny either. See 37 C.F.R. §
`42.108(a) (Board has discretion “to proceed . . . on all or some of the
`grounds of unpatentability asserted”).
`II. ANALYSIS
`A. Claim Construction
`In an inter partes review, the Board construes claims by applying the
`broadest reasonable interpretation in light of the specification. 37 C.F.R.
`§ 42.100(b); Cuozzo Speed Techs., LLC v. Lee, No. 15-446, 2016 WL
`3369425 (U.S. June 20, 2016). Under this standard, absent any special
`definitions, claim terms or phrases are given their ordinary and customary
`meaning, as would be understood by one of ordinary skill in the art, in the
`context of the entire disclosure. In re Translogic Tech., Inc., 504 F.3d 1249,
`
`6
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`1257 (Fed. Cir. 2007).
`Petitioner and Patent Owner each proffer proposed constructions of
`several claim terms. At this stage of the proceeding, neither party has
`identified a dispositive term for construction, with the possible exception of
`the “intercept” clause addressed below. For the purposes of this Decision,
`and on this record, we determine that no other claim term or clause needs
`express construction. See Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200
`F.3d 795, 803 (Fed. Cir. 1999) (only those terms which are in controversy
`need to be construed and only to the extent necessary to resolve the
`controversy).
`
`“intercept . . . a request”
`Relying partly on the ’237 FWD, Petitioner proposes that we construe
`the claim 1 phrase “intercept . . . a request” as “receiving a request
`pertaining to a first entity at another entity.” Pet. 12 (citing ’237 FWD, 11–
`13).3 Claim 16 recites a similar “intercepting a request” claims. Patent
`Owner states that “no construction [is] necessary, alternatively,” Patent
`Owner proposes that the phrase means “receiving a request to look up an
`
`
`3 In the ’237 IPR, currently on appeal at the Federal Circuit, claim 1 at issue
`in U.S. Patent No. 8,504,697 (“’697 patent”) recites a similar clause:
`“intercepting, from the first network device, a request to look up an internet
`protocol (IP) address of the second network device based on a domain name
`associated with the second network device.” ’237 FWD 4. The ’697 and
`’696 patents each have common ancestor patents at issue in Cisco, 767 F.3d
`at 1308: The ’696 patent is a continuation of an application, which like the
`’697 patent, is a continuation of U.S. Patent No. 7,921,211, which is a
`continuation of U.S. Patent No. 7,418,504 (“’504 patent”), which is a
`continuation-in-part of U.S. Patent No. 6,502,135––three of the four patents
`at issue in Cisco. See 767 F.3d at 1313. (The fourth patent at issue in Cisco,
`is U.S. Patent No. 7,490,151 (“’151 patent”), a division of the ’135 patent.)
`
`7
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`internet protocol address and, apart from resolving it into an address,
`performing an evaluation on it related to establishing a virtual private
`network communication link.” Prelim. Resp. 40. Patent Owner contends
`that its “construction appropriately captures the notion of performing an
`additional evaluation on a request related to establishing a virtual private
`network communication link, beyond conventionally resolving it and
`returning the address.” Id. at 43.
`Patent Owner’s contentions are not persuasive on this preliminary
`record. Patent Owner fails to explain sufficiently why the notion of
`“performing an additional evaluation” constitutes an implicit part of the
`claimed intercept clause. Addressing similar arguments by Patent Owner,
`the Board made a similar determination in the ’237 FWD relied upon by
`Petitioner. ’237 FWD 11 (“the record shows that the additional functionality
`urged by Patent Owner should not be imported into the intercepting
`phrase”).
`To support its construction, Patent Owner points to “DNS server 2602
`(a second entity)” as “resolving a request a request to look up an address of a
`secure target site 2604 or unsecure target site 2611 (a first entity).” Prelim.
`Resp. 42 (citing Ex. 1001, Fig. 26). Patent Owner argues that DNS server
`2602 goes “beyond merely resolving” “a request to look up a network
`address” as provide by a conventional DNS. Id. at 43. As one “example,”
`Patent Owner contends that DNS proxy 2610 (part of DNS server 2602)
`“determine[s] whether access to a secure side has been requested.” Id. at 43
`(quoting Ex. 1001, 40:26–35). Patent Owner provides two other “example”
`additional functions, but fails to describe which examples are necessary to
`the construction of the intercept clause. See id. In any event, these
`
`8
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`additional disclosed functions of a DNS fail to show that the “intercept”
`clause at issue requires the unclaimed additional functionality. The intercept
`clause does not recite a DNS.
`Furthermore, the disclosed embodiment cited by Patent Owner
`supports Petitioner’s proposed claim construction, as DNS server 2602
`performs the intercept by “receiving a request pertaining to a first entity
`[2604 or 2611] at another entity [2602].” As the ’696 patent discloses, in
`one embodiment, a “single server” having “the functions of DNS proxy
`2610 and DNS server 2609” (Ex. 1001, 40:63–65, Fig. 26) “intercepts all
`DNS lookup functions” (id. at 40:26–27). In other words, pursuant to
`requests for a connection to a secure or unsecure device (first entity),
`intercepting DNS server 2602 (second entity) returns the IP address of the
`first entity after looking up the domain name. See id. at 40:26–34.
`Based on the foregoing discussion, we adopt Petitioner’s proposed
`construction that the phrase “intercept . . . a request” means “receiving a
`request pertaining to a first entity at another entity.”
`B. Prior Art Printed Publication Status of RFC 2401
`Patent Owner asserts that Petitioner fails to show that RFC 2401 was
`publicly accessible as of November 1998 (the date recited on each of its
`pages). Prelim. Resp. 25–34; Ex. 1008. On this basis, according to Patent
`Owner, Petitioner cannot rely upon RFC 2401 as prior art to meet its burden
`of showing obviousness of the challenged claims over the combination of
`Beser and RFC 2401. See Prelim. Resp. 1, 25–26.
`The determination of whether a given reference qualifies as a prior art
`“printed publication” involves a case-by-case inquiry into the facts and
`circumstances surrounding the reference’s disclosure to members of the
`
`9
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`public. In re Klopfenstein, 380 F.3d 1345, 1350 (Fed. Cir. 2004). On its
`face, RFC 2401 is a dated “Request for Comments” from the “Network
`Working Group,” discussing a particular standardized security protocol for
`the Internet. Ex. 1008, 1. Moreover, RFC 2401 describes itself as a
`“document [that] specifies an Internet standards track protocol for the
`Internet community, and requests discussion and suggestions for
`improvements. . . . Distribution of this memo is unlimited.” Id. These
`indicia suggest that there is a reasonable likelihood the document was made
`available to the public (over the Internet), in order to obtain feedback prior
`to implementation of the standard it describes.
`To bolster its showing, Petitioner provides evidence suggesting that
`RFC 2401 would have been accessible to the interested public. For
`example, Petitioner relies on testimony by Dr. Tamassia, and an article dated
`March 15, 1999, referencing RFC 2401 availability on a website. Pet. 25
`(citing Ex. 1005 ¶¶ 115–21; Ex. 1065, 3). Petitioner also explains that RFC
`2401 describes the IPsec protocol promulgated by the Internet Engineering
`Task Force (IETF). Id. at 25. Petitioner provides a declaration by Sandy
`Ginoza, who, acting as a designated representative of the IETF, previously
`testified that RFC 2401 was published on the RFC Editor’s website and was
`publicly available in November 1998. Id. at 25–26 (citing Ex. 1060 ¶¶ 105–
`07; Ex. 1063, 39:14–24). Petitioner provides additional documentary
`evidence, in the form of an August 16, 1999 magazine article (Ex. 1064, 9
`(discussing RFC 2401 and IPsec protocols and stating “[a]ll of these
`documents are available on the IETF website”)), and an October 1996 RFC
`2026 publication (Ex. 1036, 5–6 (explaining that any interested person can
`obtain RFC documents from a number of Internet hosts using anonymous
`
`10
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`FTP, gopher, WWW, and other document-retrieval systems)). Id. at 25–26
`(citing Ex. 2064, 9; Ex.1036, 5–6). Both of these documents further
`corroborate the testimony of Sandy Ginoza and the indicia of availability on
`the face of RFC 2401.
`Patent Owner characterizes Petitioner’s showing as providing “naked
`assertions.” Prelim. Resp. 27. Patent Owner contends that Sandy Ginoza
`and Dr. Tamassia lack personal knowledge about the publication of RFC
`2401, and challenges other evidence as too general and lacking a sufficient
`foundation. See Prelim Resp. 27–30 (discussing Pet. 25, Ex. 1036, 4–6; Ex.
`1060–65)). Patent Owner does not contest Petitioner’s characterization of
`the two magazine articles, Exhibits 1064 and 1065, other than to refer to
`them as follows: “Exhibit 1064 is allegedly an article from InfoWorld
`magazine (dated August 16, 1999) and Exhibit 1065 is allegedly an article
`from NetworkWorld magazine (dated March 15, 1999).” See Prelim. Resp.
`28–29.
`The parties agree that Exhibit 1036, RFC 2026, reflects “generally
`accepted practices” for RFC documents and states that “any interested
`person can obtain RFCs from a number of Internet hosts.” See id. at 30
`(addressing Petitioner’s evidence). Patent Owner characterizes this evidence
`of “generally accepted practices” as providing “no assurance” that the
`general practices were actually applied to “RFC 2401.” Id. Notwithstanding
`Patent Owner’s argument, showing public availability would not require
`necessarily establishing such an “assurance.”
`On this preliminary record, Petitioner has made a threshold showing
`that RFC 2401 constitutes a prior art printed publication. Accordingly, we
`
`11
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`consider the disclosure of RFC 2401 as prior art for the purposes of this
`decision.
`
`C. Obviousness Over Beser and RFC 2401
`1) Overview of Beser
`Beser describes a system that establishes an IP (internet protocol)
`tunneling association on a public network between two end devices. See Ex.
`1007, Abs.
`Figure 1 of Beser is reproduced below.
`
`
`Figure 1 of Beser illustrates a network system, including public network 12,
`network devices 24 and 26, private network 20, trusted third-party network
`device 30, and modified routers or gateways 14 and 16. Ex. 1007, 3:60–
`4:19. Beser describes network devices 24 and 26 as telephony devices,
`multimedia devices, VoIP devices, or personal computers. Id. at 4:43–52.
`Beser’s system “increases the security of communication on the data
`network” by providing and hiding, in packets, “private addresses” for
`
`12
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`originating device 24 and terminating device 26 on the network. See id. at
`Abs., Fig. 1, Fig. 6. To begin a secure transaction, requesting device 24
`sends a request to initiate a tunneling connection to network device 14. Id.
`at 8:21–47. This request includes a unique identifier for the terminating end
`of the tunneling association—terminating device 26. Id.at 7:64–8:3. The
`packets used to transfer this unique identifier across the public network
`“may require encryption or authentication to ensure that the unique identifier
`cannot be read on the public network.” Id. at 11:22–25. Beser discloses, as
`background prior art, known forms of encryption for the information inside
`these packets, including IP Security (“IPsec”). Id. at 1:54–56. Once
`network device 14 receives the request, it passes the request to trusted-third-
`party network device 30. Id. at 8:3–4, 8:48–9:5.
`Trusted-third-party network device 30 contains a directory of users,
`such as a DNS, which retains a list of public IP addresses associated at least
`with second network device 16 and terminating devices 26. See id. at
`11:32–58. DNS 30 associates terminating network device 26, based on its
`unique identifier in the request, with a public IP address for router device 16.
`See id. at 11:26–36. Trusted-third-party network device 30 then assigns, by
`negotiation, private IP addresses to requesting network device 24 and
`terminating device 26. Id. at 9:29–35, 12:17–19. The negotiated private IP
`addresses are “isolated from a public network such as the Internet,” and “are
`not globally routable.” Id. at 11:62–65.
`2) Overview of RFC 2401
`RFC 2401 describes security services using IPsec protocols on the
`Internet (Ex. 1008, 3) including “access control, connectionless integrity,
`data origin authentication, [and] . . . confidentiality (encryption)” (id. at 4).
`
`13
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`According to RFC 2401, one of the IPsec goals is to provide “confidentiality
`(encryption).” Id. at 4. Using IPsec protocols
`allows the user (or system administrator) to control the
`granularity at which a security service is offered. For example,
`one can create a single encrypted tunnel to carry all the traffic
`between two security gateways or a separate encrypted tunnel
`can be created for each TCP connection between each pair of
`hosts communicating across these gateways.
`Id. at 7.
`3) Claims 1 and 16
`i) Petitioner’s Contentions
`Petitioner asserts that Beser’s streaming audio/video examples, in
`light of the encryption teachings based on the combination of Beser and
`RFC 2401, would have rendered obvious claims 1 and 16. See Pet. 29–30.
`According to Petitioner, Beser teaches or suggests most of the limitations of
`claims 1 and 16, with Beser and RFC 2401 at least suggesting encryption of
`data. See Pet. 28–34. “[T]to limit the impact from any potential disputes or
`related legal proceedings over the construction” of a VPN communications
`link, Petitioner contends that even if a VPN communications link requires
`data encryption, the combination of Beser and RFC 2401 would have
`rendered such a VPN link obvious. See id. at 29.4
`
`
`4 According to Cisco, “the [related ’151] patent consistently differentiates
`between ‘security’ and ‘encryption.’ Both the claims and the specification
`of the ’151 patent make clear that encryption is a narrower, more specific
`requirement than security.” Cisco, 767 F.3d at 1323. Cisco refers to
`“physical security” on private networks that do not necessarily have
`encryption, notes that the VirnetX patents (at issue in that litigation) describe
`encryption as one possible way to tackle data security, and notes that the
`district court’s claim construction for security only requires encryption on
`
`14
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`Addressing the preambles claims 1 and 16, Petitioner contends that
`the claimed first network device reads on Beser’s originating end device 24,
`and that the claimed second network device reads on Beser’s terminating
`end device 26. See id. at 35–36 (citing Ex. 1007, 8:15–20, 21:52–62, 22:2–
`22; Ex. 1005 ¶¶ 127, 195–96); Ex. 1007, Fig. 1. Petitioner points out that
`Beser discloses various end devices including WebTV devices and VoIP
`devices that communicate over a private tunneling association established by
`trusted-third party network device 30 “with the help of first and second
`network devices” 14 and 12. See Pet. 35 (citing Ex. 1007, 4:43–54, 7:64–66,
`8:15–20, 14:51–67, 10:22–36, 10:55–66, 14:51–67; Ex. 1005 ¶¶ 131, 169,
`173, 177, 188–93, 198).
`Regarding the “intercept” clause of claim 1, Petitioner explains that
`Beser’s trusted-third-party network device 30 (which includes a DNS), first
`network device 14, and second network device 12, work together such that
`devices 30 and 14 look up private and public IP addresses based on a request
`from originating VoIP device 24 that includes a unique domain name for the
`claimed target device––terminating end device 26. See id. at 36–39 (citing
`Ex. 1007 4:9–11, 8:21–47, 10:37–42, 10:55–11:5, 11:26–36, 11:45–58,
`13:49-65, 14:2–14, 16:1–37; Ex. 1005 ¶¶ 66, 152–53, 170–72, 175–78, 192–
`92; ’237 FWD 24, 26 n.6, 27). According to Petitioner, Beser’s first
`network device 14 and trusted-third-party device 30 constitute “another
`entity” that intercepts the request according to the claim construction of
`“intercept” as set forth above. Id. at 38–39.
`
`
`insecure paths (for example, on the Internet––as opposed to physically
`secure private networks). See id. at 1321–22.
`
`15
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`Regarding the “determine” clause of claim 1, Petitioner contends that
`“Beser teaches that the trusted-third-party network device [30] determines
`whether the unique identifier in a request specifies a destination that can
`establish a secure tunnel by checking its internal database of registered users
`or devices.” Id. at 39 (citing Ex. 1007, 11:30–36, 11:45–58; Ex. 1005 ¶¶
`163, 176, 178, 180). According to Petitioner, “[t]his is done ‘in response to
`the request’ and is the same type of ‘determining’ disclosed in the ’696
`patent.” Pet. 39 (citing Ex. 1001, 40:28–35; ’237 FWD 28–36).
`Petitioner also contends that Beser’s system implies integrating
`normal DNS functionality with requests for tunneling, as implied by the use
`of unique domain name (or other identifier) functioning as part of a request
`for secure tunneling, and the disclosure of a conventional DNS. See Pet. 21
`(citing Ex. 1007, 4:7–42; 8:21–52, 9:6–11, 11:26–58: Ex. 1005 ¶¶ 152–53,
`160–63, 170, 175). In other words, according to Petitioner, a skilled artisan
`would have understood that Beser’s DNS would have been a modified
`conventional DNS equipped to handle requests to communicate using
`Beser’s IP tunnel and to handle typical DNS requests. See Pet. 19–22, 39–
`41; Ex. 1007, 8:21–51, 9:26–30, 11:8–12:19; Figs. 1, 6, 9; Ex. 1005
`¶¶ 156–164, 170–71, 176–83.
`Regarding the “initiate a [VPN] communication link” clause recited in
`claim 1, Petitioner argues that the combination of Beser and RFC 2401
`would have rendered obvious encryption of at least low resolution audio and
`video packet information on Beser’s tunnel. Pet. 41–44. Petitioner also
`contends that based on the combination of Beser and RFC2401, a skilled
`artisan would have recognized that any problems associated with encryption
`of high-volume multimedia traffic may be overcome by providing more
`
`16
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`computing power, and that the combination would have rendered obvious
`end-to-end encryption in Beser’s system. See id. at 42–44 (citing ’237 FWD
`40, 43; Ex. 1007, 2:13–17). Petitioner also contends that the initiating the
`VPN connection would be based on a determination that Beser’s terminating
`end device is available for the secure communications service, because, for
`example, if the device is not listed in Beser’s DNS as associated with a
`private IP for tunneling, it would not be available for tunneling, and no
`secure connection will be made. See Pet. 40–43; Ex. 1005 ¶¶ 176–83
`(testifying, inter alia, that it would have been obvious to configure Beser’s
`DNS to return an IP address if the unique domain name was not registered
`for secure use).
`Petitioner also contends that the combination of Beser and RFC 2401
`teaches or suggests the remaining elements of claims 1 and 16, including the
`preamble of “including one or more servers configured to” perform the
`functions recited in claim 1. See Pet. 44 (citing Ex. 1007, 4:9–11, 4:18–5:2,
`5:15–47, 10:37–42, 10:55–11:5; Ex. 1005 ¶¶ 130, 146, 156).
`
` Regarding reasons to combine, Petitioner contends that “a person of
`ordinary skill would have considered the teachings of Beser in conjunction
`with those in RFC 2401 because Beser expressly refers to the IPsec protocol
`(which is defined in RFC 2401) as being the conventional way that the IP
`tunnels described in Beser are established.” Pet. 31 (citing Ex. 1007, 1:54–
`56; Ex. 1005 ¶¶ 218–20, 230). Petitioner adds that Beser also indicates that
`“its IP tunneling schemes are compliant with standards-based processes and
`techniques (e.g., IPsec), and can be implemented using pre-existing
`equipment and systems,” and that “IP tunnels are and should ordinarily be
`encrypted, even for the data streaming examples.” Id. at 31–32 (citing Ex.
`
`17
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`1007, 1:54–56, 4:55–5:2, 11:22–25, 18:2–5; Ex. 1005 ¶¶ 135–36, 135–36,
`138, 221, 223–25, 229, 233–38). Petitioner also contends that Beser
`discloses encryption employed to hide addresses in its tunneling scheme,
`criticizes prior art systems that do not use encryption, discusses challenges
`to data encryption, and implies a trade-off between power and data quality
`for audio and video streaming. See Pet. 32–35; Ex. 1007, 1:54–2:40, 11:22–
`25, 18:2–5, 20:11–14.
`
` Petitioner contends further that a person of ordinary skill would have
`recognized that IPsec, which Beser and RFC2401 each discloses, readily
`could have been integrated into Beser’s systems, for example, to provide
`end-to-end enhanced security of Beser’s tunneling (which provides
`anonymity by hiding addresses using encryption and private addresses) and
`using encryption to provide secure data security. See id. 32–33 (citing Ex.
`1005 ¶¶ 224–25, 228–29, 233–35). Petitioner explains that basic
`configurations, including edge routers, of the two disclosed systems as
`disclosed in Beser and RFC 2401, are similar. Id. at 33 (citing Ex. 1005
`¶¶ 231–32, 234; Ex. 1007, 4:7–8, 18–29, Fig. 1; Ex. 1008, 25); see Ex. 1005
`¶¶ 221–32 (comparing RFC2401 and Beser, discussing tunnels and
`encryption, testifying that skilled artisans readily would have been motivated
`to use data encryption to enhance security in VPNs by adding computing
`power if necessary).
`
`18
`
`
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`ii) Patent Owner’s Arguments
`a. Intercept a Request to Look Up an Internet Protocol (IP)
`Address of the Second Network Device Based On a
`Domain Name Associated With the Second Network Device
`
`
`Patent Owner contends that Beser’s “negotiation does not involve
`looking up any IP address, but rather involves assignment of a first private
`network address to the originating device and a second private network
`address to the terminating device.” Prelim. Resp. 10. Patent Owner
`explains that “Beser never suggests that this [domain name] data structure is
`looked up,” and “only teaches that when a trusted-third-party network device
`30 is informed of a request to initiate a tunnel, it associates a public IP
`address of a second network device 16 with the unique identifier of
`terminating telephony device 26.” Id. at 10 (citing Ex. 1007, 11:26–32; Ex.
`2018 ¶ 44) (emphasis added).5
`These arguments appear to attempt to draw a distinction between
`“look up” and “associates” that does not exist on this preliminary record.
`Beser’s system must “look up” an IP address based on a domain name (or
`other unique identifier) in order to associate an IP address or other addresses
`with terminating telephony device 26. See Ex. 1007, 10:37–11:58, Figs. 6–
`7. Like Patent Owner, Dr. Monrose does not explain the basis for any such
`distinction. See Ex. 2018 ¶ 44. As Petitioner contends and as summarized
`above, Beser’s system includes a DNS. See, e.g., Ex. 1007, 10:41–57,
`
`
`5 Exhibit 2018 refers to the Declaration of Fabian Monrose, Ph.D., submitted
`by Patent Owner in related IPR2015-00866.
`
`19
`
`

`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`11:33–34.6 The ’696 patent and the record support Petitioner’s preliminary
`showing that DNS look up functions were conventional and well-known.7
`On this limited record, notwithstanding Patent Owner’s arguments, Beser
`discloses (or at least sugges