Trials@uspto.gov
`571-272-7822
`
`
`
`
`
`
`
`Paper 41
`Date: May 11, 2015
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`____________
`
`Case IPR2014-00237
`Patent 8,504,697 B2
`____________
`
`
`
`Before MICHAEL P. TIERNEY, KARL D. EASTHOM, and
`STEPHEN C. SIU, Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`
`
`
`571-272-7822
`
`
`
`
`
`
`
`Paper 41
`Date: May 11, 2015
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`____________
`
`Case IPR2014-00237
`Patent 8,504,697 B2
`____________
`
`
`
`Before MICHAEL P. TIERNEY, KARL D. EASTHOM, and
`STEPHEN C. SIU, Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`
`I. BACKGROUND
`
`Petitioner, Apple Inc., filed a Petition (Paper 1,“Pet.”) seeking an inter
`partes review of claims 1–11, 14–25, and 28–30 of U.S. Patent No.
`8,504,697 B2 (Ex. 1001, “the ’697 patent”) pursuant to 35 U.S.C. §§ 311–
`319. After VirnetX, Patent Owner, filed a Preliminary Response (Paper 12),
`we instituted an inter partes review of claims 1–11, 14–25, and 28–30
`(Paper 15, “Institution Decision” or “Inst. Dec.”).
`Subsequent to institution, Patent Owner filed a Patent Owner
`Response (Paper 30) (“PO Resp.”), and Petitioner filed a Reply (Paper 33)
`(“Pet. Reply”) thereto. An Oral Hearing was conducted on February 9,
`2015, and then transcribed. See Paper 40.
`The Board has jurisdiction under 35 U.S.C. § 6(c). This Final Written
`Decision issues pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73.
`For the reasons that follow, we determine that Petitioner has shown by
`a preponderance of the evidence that claims 1–11, 14–25, and 28–30 of the
`’697 patent are unpatentable.
`A. The ’697 Patent (Ex. 1001)
`The ’697 patent describes secure methods for communicating over the
`internet. Ex. 1001, 10:7–8. To provide a secure network, the ’697 patent
`system employs proxy domain name servers (DNS). The ’697 patent
`describes conventional DNSs as follows:
`Conventional Domain Name Servers (DNSs) provide a look-up
`function that returns the IP [Internet Protocol] 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
`
`2
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`
`and then used by the browser to contact the destination web
`site.
`Ex. 1001, 39:32–38.
`To set up the secure network or Virtual Private Network (“VPN”), a
`proxy DNS determines whether the user has requested access to a secure site
`and may determine whether the user has sufficient security privileges to
`access that site. Ex. 1001, 40:31–37, 41:6–64. To make both
`determinations, the proxy DNS provides DNS look-up functions for secure
`hosts. Id. at 40:31–37. The proxy DNS may use a domain name extension
`or an internal table of sites, or may request security information about the
`user. Id. at 40:31–37, 41:14–27. If the user has requested access and has
`sufficient security privileges, the proxy DNS requests a gatekeeper to set up
`a secure communication link by passing a “resolved” address or “hopblocks”
`for the user and target addresses. See Ex. 1001, 40:37–65, Fig. 27. Any of
`various packet fields can be “hopped,” for example, “IP source/destination
`addresses” or “a field in the header.” Ex. 1001, 41:38–39. If the user lacks
`sufficient security privileges, the system returns a “HOST UNKNOWN”
`error message. Ex. 1001, Fig. 27.
`In essence, the system provides security through anonymity of IP
`addresses––the proxy server does not send back the true IP address of the
`target computer. See Ex. 1001, 40:1–20. For example, the proxy server may
`receive the client’s DNS request, which forwards it to a gatekeeper, which
`returns a “resolved” destination address to the proxy based on a “resolved”
`name, which then forwards the “resolved address” back to the client “in a
`secure administrative VPN.” See Ex. 1001, 41:49–56.
`
`3
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`
`B. Illustrative Claim
`Claim 1 of the ’697 patent is reproduced below:
`1. A method of connecting a first network device and
`a second network device, the method comprising:
`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;
`determining, in response to the request, whether the
`second network device is available for a secure communications
`service; and
`initiating a secure 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
`secure communication link to communicate at least one of
`video data and audio data between the first network device and
`the second network device.
`
`
`D. Instituted Grounds of Unpatentability
`We instituted an inter partes review on the following grounds and
`claims.
`References
`
`Basis
`
`Claims Challenged
`
`Beser
`Beser and RFC 2401
`
`
`§ 102
`§ 103
`
`1–11, 14–25, and 28–30
`1–11, 14–25, and 28–30
`
`4
`
`C. Prior Art
`US 6,496,867 B1 Dec. 17, 2002
`
`Beser
`
`S. Kent and R. Atkinson, Security Architecture for the Internet Protocol,
`Request for Comments: 2401, BBN Corp., November 1998 (“RFC 2401”)
`(Ex. 1010).
`
`
`(Ex. 1009)
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`
`E. Claim Interpretation
`In an inter partes review, the Board construes claim terms in an
`unexpired patent under their broadest reasonable construction in light of the
`specification of the patent in which they appear. In re Cuozzo Speed Techs.,
`LLC, 778 F.3d 1271, 1281 (Fed. Cir. 2015); 37 C.F.R. § 42.100(b); Office
`Patent Trial Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012).
`With the exception of slight modifications to some of the terms discussed
`below, we adopt and incorporate the claim constructions set forth in the
`Institution Decision. See Inst. Dec. 7–15.
`i. Secure Communication Link
`In the Institution Decision, we determined, under the broadest
`reasonable construction standard, that a “secure communication link,” as
`recited in claims 1 and 16, is “a transmission path that restricts access to
`data, addresses, or other information on the path, generally using obfuscation
`methods to hide information on the path, including, but not limited to, one or
`more of authentication, encryption, or address hopping.” Inst. Dec. 10.
`Patent Owner argues that the term “secure communication link” must
`include encryption. See, e.g., PO Resp. 10–19.
`Notwithstanding Patent Owner’s arguments that security requires
`encryption, the ’697 patent Specification states that “[a] tremendous variety
`of methods have been proposed and implemented to provide security and
`anonymity for communications over the Internet.” Ex. 1001, 1:35–37
`(emphasis added). The ’697 patent Specification also describes data security
`and anonymity as counterpart safeguards against eavesdropping that may
`occur while two computer terminals communicate over the Internet. See id.
`at 1:38–54. Security, in one context, may refer to protection of the data
`
`5
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`itself, to preserve the secrecy of its contents, while anonymity refers to
`preventing an eavesdropper from discovering the identity of a participating
`terminal. See id. at 1:40–56. Further according to the ’697 patent
`Specification, the concept of security generally includes “two security
`issues,” address (anonymity) and data security, with “a desire[] for the
`communications to be secure, that is, immune to eavesdropping.” Id. at
`1:42–43, 54–56.
`This understanding is also consistent with the Federal Circuit’s
`construction of this term in an appeal of a related case. Shortly after Patent
`Owner filed its Response, the Federal Circuit determined that the term does
`not require encryption in a related case involving VirnetX, Inc.’s patent
`claims of similar scope, based on similar arguments by VirnetX. See
`VirnetX, Inc. v. Cisco Systems, Inc., 767 F.3d 1308, 1317–19 (Fed. Cir.
`2014).1 Relying on passages that also appear in the ’697 patent
`Specification in the same context, the court determined that a “secure
`communication link” (as used in the ’504 and ’211 ancestor patents, see note
`1), is “a direct communication link that provides data security and
`anonymity.” See Cisco, 767 F.3d at 1319. In Cisco, the court found that
`“[b]oth the claims and the specification of the ’151 patent make clear that
`encryption is a narrower, more specific requirement than security.” Id. at
`1323 (citing a passage in the ’151 patent at 1:49–50 that also appears in the
`
`
`1 The ’697 patent is a continuation of U.S. Patent No. 7,921,211 (“’211
`patent”), 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 (“’135
`patent”), three of the four patents at issue in Cisco. See 767 F.3d at 1313.
`Also at issue in Cisco, is U.S. Patent No. 7,490,151 (“’151 patent”), a
`division of the ’135 patent.
`
`6
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`’697 patent at 1:57–60: “Data security is usually tackled using some form of
`data encryption.”
`Central to its claim construction, the court found, based on
`concessions or arguments by the parties, that the ordinary meaning of the
`term “security,” on that record, did not apply. See id. at 1317 (“There is no
`dispute that the word ‘secure’ does not have a plain and ordinary meaning in
`this context, and so must be defined by reference to the specification.”).
`In not requiring encryption, Cisco additionally found on that record
`that security includes “physical security.” See Cisco, 767 F.3d at 1322
`(“VirnetX provided substantial evidence for the jury to conclude that paths
`beyond the VPN server may be rendered secure and anonymous by means of
`‘physical security’ present in the private corporate networks connected to by
`VPN On Demand.”). Underlying that finding, Cisco noted that “VirnetX’s
`expert testified that one of ordinary skill would understand that the path . . .
`within the private network[] would be secure and anonymous owing to the
`protection provided by the private network.” Id. at 1321.
`Of course, anonymity provides some security, as explained in Cisco.
`The claim construction in the Institution Decision also includes anonymity
`as a form of security, but not as a necessary requirement. Instead, our
`construction also includes address hopping, restricting access to addresses,
`and generally, obfuscation methods. This is not inconsistent with the
`Federal Circuit’s construction. In contrast to the broadest reasonable
`interpretation standard employed by the Board for an unexpired patent, the
`Federal Circuit employs a narrower claim construction standard when
`reviewing the construction of a claim applied by the district court. See In re
`Rambus, Inc., 694 F.3d 42, 46 (Fed. Cir. 2012) (contrasting the Board’s
`
`7
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`review of expired patents, which is “similar to that of a district court’s
`review,” with the Board’s review of unexpired patents, which involves the
`broadest reasonable interpretation standard); Cuozzo, 778 F.3d at 1281
`(broadest reasonable interpretation standard applies to AIA proceedings). In
`any event, anonymity is not a central issue, because the Beser reference
`discloses it and the parties do not raise it. See Ex. 1009, Abstract, 12:16–19.
`Accordingly, in this case, it is not necessary to determine if a secure
`communication link, under the broadest reasonable construction standard,
`necessarily includes anonymity (or a direct link).2
`Based on the foregoing discussion, the term may include encryption,
`anonymity, and physical security. Therefore, we slightly modify our
`construction of the term as set forth in our Institution Decision. The
`broadest reasonable construction of a “secure communication link” is “a
`transmission path that restricts access to data, addresses, or other
`information on the path, generally using obfuscation methods to hide
`information on the path, including, but not limited to, one or more of
`anonymity, authentication, or encryption.”
`ii) Virtual Private Network (VPN) Communication Link
`Claims 3 and 17 respectively depend from claims 1 and 16 and further
`limit those claims by reciting “wherein the secure communication link is a
`virtual private network [(VPN)] communication link.” In the Institution
`Decision, we construed a VPN to include “a secure communication link that
`
`
`2 Notwithstanding Cisco’s “direct” component of a “secure communication
`link,” Patent Owner argues that it “do[es] not appear relevant to the parties’
`disputes.” PO Resp. 14 n.1. Similarly, the parties do not propose that
`anonymity is a requirement in their latest papers. See Pet. Reply 4
`(suggesting anonymity is not relevant); PO Resp. 19 (same).
`
`8
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`includes a portion of a public network.” Inst. Dec. 12. The construction was
`based largely on the finding that the parties did not provide a clear
`distinction between a secure and VPN communications link, evidence of
`ordinary meaning provided by Petitioner (see, e.g., Ex. 1073, 2–5), and the
`finding that the ’697 patent Specification “explains [that] a ‘secure
`communication link’ is ‘a virtual private communication link over the
`computer network.’” Inst. Dec. 11 (quoting Ex. 1001, 6:63–65, also relying
`on Ex. 1073, Ex. 1024). By way of background, one commentator generally
`describes a VPN as a collection of devices that can communicate (i.e., a
`network) over a public network with a desired level of privacy obtained by
`controlling access and security of data (i.e., virtually private). See Ex. 1073,
`2–6.
`
`Patent Owner argues that “the term VPN is not in dispute here and is
`not a claim term,” so “the Board need not construe it.” PO Resp. 19. Patent
`Owner characterizes the recited term, “a [VPN] communication link,” as
`“related [to] but different” from, a VPN. Id. Referring to a VPN
`communication link, Patent Owner urges that “the Board need not construe
`this term . . . and [its construction] does not appear to impact any of the
`issues in this case.” PO Resp. 21.
`Nevertheless, according to Patent Owner, Beser does not disclose a
`VPN. PO Resp. 54. This stance mandates a construction of the term on this
`record. Patent Owner maintains that a “VPN communication link” is “a
`communication path between computers in a virtual private network.” PO
`Resp. 21. Regarding the construction of a “VPN” as “a secure
`communication link with the additional requirement that the link includes a
`portion of the public network” (Inst. Dec. 11–12), Patent Owner “does not
`
`9
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`dispute the ‘secure communication link’ aspect of the Decision’s
`construction,” except to the extent that it lacks the encryption and direct link
`requirements discussed above in the construction of a secure communication
`link. See PO Resp. 20 & n.4. As discussed above (note 2), Patent Owner
`maintains that the “direct” requirement is not at issue in this proceeding, and
`in line with Cisco, we determined that encryption is not a necessary
`requirement of a secure communication link.
`The parties do not set forth explicitly what a VPN constitutes. In
`Cisco, the court indicates, as construed in the ancestor ’504 patent (supra
`note 1), that a VPN provides anonymity: “Moreover, in several instances
`the specification appears to use the terms ‘secure communication link’ and
`‘VPN’ interchangeably, suggesting that the inventors intended the disputed
`term to encompass the anonymity provided by a VPN.” 767 F.3d at 1318.
`Although a VPN as construed by Cisco includes anonymity, neither
`party argues for that requirement in their latest papers. And as noted, Patent
`Owner maintains that the construction of VPN “does not appear to impact
`any of the issues in this case.” PO Resp. 21. Claims 3 and 17 depend from
`claims 1 and 16, suggesting pursuant to claim differentiation that a VPN
`communication link is narrower than a secure communication link.
`Therefore, for purposes of this proceeding, the broadest reasonable
`construction of a “virtual private network communication link” is “a secure
`communication link that includes a portion of a public network,” as set forth
`in the Institution Decision. Inst. Dec. 11–12.
`iii) Intercepting A Request
`In the Institution Decision, we construed “intercepting a request,” as
`recited in claim 1, as “receiving a request pertaining to a first entity at
`
`10
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`another entity.” Inst. Dec. 13. Claim 16 recites a similar term (i.e.,
`“intercept . . . a request”). Patent Owner “disagrees with this construction”
`(PO Resp. 23), but “believes that no construction is necessary” (id. at 26),
`because “it does not appear that the construction of ‘intercepting’ will bear
`on the outcome of the issues in this inter partes review” (id. at 23).
`Nevertheless, Patent Owner urges that if we construe the term, we adopt
`Patent Owner’s construction: “receiving a request to look up an internet
`protocol address and, apart from resolving it into an address, preforming an
`evaluation on it related to establishing a secure communication link.” Id. at
`23.
`
`To support its proposed alternative construction, Patent Owner
`maintains that “[t]he Decision’s construction addresses a common aspect of
`a conventional DNS and the disclosed embodiments, namely that a request to
`look up an address of one entity may be received at another entity.
`However, the construction overlooks the aspects distinguishing the
`‘intercepting’ phrase from conventional DNS.” Id. at 26 (emphases added)
`(citation omitted). According to Patent Owner, a disclosed modified DNS
`“appl[ies] an additional layer of functionality to a request to look up a
`network address beyond merely resolving it and returning the network
`address.” Id. at 25. As an “example, the DNS proxy 2610 may intercept the
`request and ‘determin[e] whether access to a secure site has been
`requested.’” Id. (quoting Ex. 1001, 40:31–33).
`Patent Owner’s arguments and the record show that Patent Owner’s
`proposed construction adds unnecessary functionality to “intercepting a
`request.” According to Patent Owner’s arguments, and as Petitioner points
`out, another recited phrase in claim 1 (and a similar phrase in claim 16),
`
`11
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`captures the functionality, in particular, the “determining . . . whether”
`phrase of claim 1, which is recited after the intercepting phrase. See Pet.
`Reply 4–5 (“Patent Owner’s illogical construction . . . is actually part of the
`next step of the claims.”); see also PO Resp. 26 (“The independent claims
`also support this [functionality], for example, by reciting that a
`determination is made whether the second network is available for a secure
`communications service . . . .”). In other words, Patent Owner argues that
`the “determining . . . whether” clause covers functionality that it also urges
`is implicit in the intercepting phrase. See PO Resp. 26, 29–30. Based on the
`foregoing discussion, the record shows that the additional functionality
`urged by Patent Owner should not be imported into the intercepting phrase.
`Accordingly, as set forth in the Institution Decision, the broadest reasonable
`construction of the term “intercepting a request” is “receiving a request
`pertaining to a first entity at another entity.”
`iv) Determining, In Response To The Request, Whether
`The Second Network Device Is Available For Communication
`In the Institution Decision, we construed the above phrase, as recited
`in claim 1 (and similarly in claim 16), to “include[] determining, one or
`more of 1) whether the device is listed with a public internet address, and if
`so, allocating a private address for the second network device, or 2) some
`indication of the relative permission level or security privileges of the
`requester.” Inst. Dec. 15. Petitioner implicitly agrees with this construction.
`See Pet. Reply 5–6.
`Patent Owner asserts that this construction “imports unnecessary
`language into the claims.” PO Resp. 27. Patent Owner maintains that there
`is no reason to require “an allocation of a private address,” because that step
`does not aid in determining availability. See id. at 27–28. Patent Owner
`
`12
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`also argues that the construction eliminates the requirement of the
`determination being made “in response to the request.” See id. at 30. Patent
`Owner also maintains that “[t]he claim language is plain on its face . . . .
`[and] does not require construction.” See id.
`Patent Owner’s arguments show persuasively that the preliminary
`construction was too narrow. The term “available” has an ordinary meaning
`of “accessible for use; at hand; usable.” Ex. 3004.3 Based on the arguments
`presented, the ordinary meaning of the term “available,” and the ’697 patent
`Specification, we modify our previous claim construction as follows: The
`term “determining, in response to the request, whether the second network
`device is available for secure communication,” means “determining, in
`response to a request, whether the second network device is accessible for
`use, at hand, or usable for a secure communication.”
`Interpreting the “determining” phrase, Patent Owner directs attention
`to a passage in the ’697 patent Specification, “‘determin[ing] whether access
`to a secure site has been requested.’” PO Resp. 29 (quoting Ex. 1001,
`40:32–33, modified by Patent Owner). The sentence immediately following
`this cited passage supports the view that gauging the requester’s security
`privileges may help to determine whether a device is accessible:
`If access to a secure a secure site has been requested (as
`determined, for example, by a domain name extension, or by
`reference to an internal table of such sites), DNS proxy 2610
`determines whether the user has sufficient security privileges to
`access the site.
`Ex. 1001, 40:33–37.
`
`
`3 THE AMERICAN HERITAGE DICTIONARY OF THE ENGLISH LANGUAGE 90
`(1975).
`
`13
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`
`More importantly, the first quoted sentence in the passage indicates
`that determining whether a device is “available for a secure communication
`service” is broad enough to mean determining whether the device is listed on
`a network database that a secure network uses to obtain access to secure
`target devices.
`Patent Owner argues that focusing on the requester’s security level,
`and by implication, the relative security levels of the requester and the
`device, is not required: The “‘determining’ phrase need not be limited to the
`Decision’s determining ‘permission level or security privileges of the
`requester.’” PO Resp. 29 (emphasis added, citing Ex. 2025 ¶ 30).
`Therefore, the quoted passage from the Specification, bolstered by Patent
`Owner’s argument, indicates that determining if a secure device is listed in
`an “internal table” (or similar database structure) of secure sites is sufficient
`to constitute a determination of availability.
`As part of the disclosed process, the system returns a “resolved
`address” for the target device: “The address that is returned need not be the
`actual address of the destination computer.” Ex. 1001, 40:45–49.
`Another passage describes a normal DNS “look-up function”:
`For DNS requests that are determined to not require secure
`services (e.g., an unregistered user), the DNS server
`transparently “passes through” the request to provide a normal
`look-up function and return the IP address of the target
`web server, provided that the requesting host has permissions
`to resolve unsecured sites. Different users who make an
`identical DNS request could be provided with different results.
`Ex. 1001, 40:14–20.
`In summary, according to disclosed embodiments in the ’697 patent
`Specification, a device may be determined to be available as a secure device
`
`14
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`that the system provides, for example, by determining that the device is
`listed for use as part of the secure system. According to one of the above
`disclosed examples, which is not limiting, different users may be denied or
`granted access depending on that particular user’s security privileges relative
`to the target’s security level, rendering that device available or unavailable
`to that user.
`Based on the foregoing discussion, according to the ’697 patent
`Specification and the arguments presented, “determining, in response to a
`request, whether a second network device is available for secure
`communication,” means “determining if the second network device is
`accessible for use, at hand, or usable, in a system that provides secure
`communication using that device.”
`II. ANALYSIS
`A. Beser
`Beser describes a system that establishes an IP (internet protocol)
`tunneling association between two end devices 24 and 26 on private
`networks, using first and second network devices 14 and 16, and trusted-
`third-party network device 30, over public network 12. See Ex. 1009,
`Abstract, Fig. 1; Pet. 16.
`
`15
`
`
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`
`Figure 1 of Beser follows:
`
`
`Figure 1 above represents Beser’s system, which includes the Internet
`as public network 12, network end devices 24 and 26, private networks 20,
`trusted-third-party device 30, and modified router or gateway network
`devices 14 and 16. See Ex. 1009, Abstract, 3:60–4:18.
`
`Beser’s system “increases the security of communication on the data
`network” by providing and hiding, in packets, “private addresses” for
`originating device 24 and terminating device 26 on the network. See id. at
`Abstract, Fig. 1, Fig. 6. To begin the process for a secure transaction, at step
`102, requesting device 24 sends to network device 14, as part of its request,
`an indicator that “may be a distinctive sequence of bits [that] indicates to the
`tunneling application that it should examine the request for its content and
`not ignore the datagram.” Ex. 1009, 8:40–44, Figs. 1, 4. The request (which
`may include a series of packets) also includes a unique identifier, such as a
`domain name, employee number, telephone number, social security number,
`a public IP address 58, or other similar identifier, associated with
`terminating device 26. Ex. 1009, 10:37–11:8, 11:9–12. At step 104,
`
`16
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`network device 14 informs trusted-third-party network device 30 of the
`request. See id. at 7:64–8:7, 11:9–20, Fig. 4.
`
`Trusted-third-party 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 devices 16 and terminating devices 26. See id. at 11:32–58.
`At step 106 (and parallel step 116), DNS 30 associates terminating network
`device 26, based on its unique identifier (e.g., domain name, or other
`identifier) in the request, with a public IP address for router device 16 (i.e.,
`the association of the domain name with other stored information, including
`Internet addresses, shows they are connected together at the edge of public
`network 12). See Ex. 1009, 11:26–36, Figs. 1, 4, 5.4 As indicated, DNS 30
`includes, in a directory database or otherwise, stored public IP addresses for
`router 16 and terminal device 26, and other data that associates devices 16
`and 26 together. Id. at 11:48–52. In other words, trusted-third-party
`network device DNS 30, includes the “IP58 addresses for the terminating . . .
`device[s] 26,” and uses “data structures . . . known to those skilled in the art
`. . . for the association of the unique identifiers [for terminating devices 26]
`and IP 58 addresses for the . . . network devices 16”––including domain
`names as unique identifiers, as noted above. Id. at 11: 2–5, 32–36, 48–55.
`At step 108 (or step 118), Beser’s system assigns, by negotiation,
`private IP addresses to requesting network device 24 and terminating device
`26. See id. at 11:59–12:19, 12:38–48, Figs. 4, 5. In an exemplary
`embodiment, trusted-third-party network (DNS) device 30 performs the
`
`
`4 Figure 5, which includes step 116, involves a specific Voice-over-Internet-
`Protocol (VoIP) application of the general process of Figure 4, which
`includes parallel step 106. See Ex. 1009, 3:26–30.
`
`17
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`negotiation for private addresses in order to further ensure anonymity of end
`devices 24 and 26 (though device 30 need not be involved in the negotiation
`in one embodiment). 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:63–65. “These IP 58 addresses may be
`stored in network address tables on the respective network devices, and may
`be associated with physical or local network addresses for the respective
`ends of the VoIP [(Voice-over- Internet-Protocol)] association by methods
`known to those skilled in the art.” Id. at 12:33–37.
`The negotiated private IP addresses may be “inside the payload fields
`84 of the IP 58 packets and may be hidden from hackers on the public
`network 12.” Id. at 12:15–16. The IP packets “may require encryption or
`authentication to ensure that the unique identifier cannot be read on the
`public network 12.” Id. at 11:22–25; see also 20:11–14 (disclosing
`encryption or authentication of first IP 58 packet to ensure hiding the
`address of the public IP address of network device 16). Beser also discloses,
`as background prior art, known forms of encryption for “the information
`inside the IP packets,” including IP Security (“IPSec”). Id. at 1:54–56.
`
`Beser describes edge routers, such as network devices 14 and 16, as
`devices that route packets between public networks 12 and private networks
`20. Id. at 4:18–24. End devices 24 and 26 include network multimedia
`devices, VoIP devices, or personal computers. Id. at 4:43–54.
`B. RFC 2401
`According to RFC 2401, IPsec provides a “set of security services,”
`including “access control, connectionless integrity, data origin
`
`18
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`authentication, [and] . . . confidentiality (encryption).” Ex. 1010, 4. RFC
`2401 describes IPsec further, as follows:
`IPsec 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.
`
`The “security services use shared secret values (cryptographic keys)
`
`. . . . (The keys are used for authentication/integrity and encryption
`services).” Id.
`
`C. Representative Claims
`As indicated above, Petitioner asserts that Beser anticipates, or
`alternatively, that the combination of Beser and RFC 2401 renders obvious,
`claims 1–11, 14–25, and 28–30. See Pet. 16–38. Patent Owner presents
`separate patentability arguments for claims 1, 2, and 3, with parallel
`arguments for claims 16, 17, and 24. See PO Resp. 36–56. Patent Owner
`asserts that the remaining challenged claims are patentable because they
`depend from claims 1 or 16. PO Resp. 52. Accordingly, this Final Written
`Decision focuses on claims 1, 2, and 3 as representative of the challenged
`claims.
`
`D. Anticipation
`i) Encryption and Secure Communication Link
`Patent Owner, supported by its declarant Dr. Fabian Newman
`Monrose in the Monrose Declaration (Ex. 2025), argues that Beser does not
`disclose encryption and therefore does not disclose a “secure communication
`
`19
`
`
`
`IPR2014-00237
`Patent 8,504,697 B2
`
`link” as required by claims 1 and 16. PO Resp. 49–52. As set forth above,
`according to Cisco and the claim construction, a secure communication link
`does not require encryption. Petitioner contends that even if a secure
`communication link requires encryption, Beser discloses at least some
`encryption for initial IP packets, and, in
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
