Trials@uspto.gov
`Tel: 571-272-7822
`
`
`
`
`Paper 31
`Entered: May 30, 2018
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE, INC.,
`
`Petitioner,
`
`v.
`
`VIRNETX, INC.,
`
`Patent Owner.
`____________
`
`Case IPR2017-00337
`Patent 9,038,163 B2
`____________
`
`
`Before KARL D. EASTHOM, KEVIN W. CHERRY1, and
`KEVIN C. TROCK, Administrative Patent Judges.
`
`TROCK, Administrative Patent Judge.
`
`
`
`
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and
`37 C.F.R. § 42.73
`
`
`
`
`1 Judge Cherry replaced Judge Bisk on the panel following the hearing.
`
`
`Tel: 571-272-7822
`
`
`
`
`Paper 31
`Entered: May 30, 2018
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE, INC.,
`
`Petitioner,
`
`v.
`
`VIRNETX, INC.,
`
`Patent Owner.
`____________
`
`Case IPR2017-00337
`Patent 9,038,163 B2
`____________
`
`
`Before KARL D. EASTHOM, KEVIN W. CHERRY1, and
`KEVIN C. TROCK, Administrative Patent Judges.
`
`TROCK, Administrative Patent Judge.
`
`
`
`
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and
`37 C.F.R. § 42.73
`
`
`
`
`1 Judge Cherry replaced Judge Bisk on the panel following the hearing.
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`
`I. INTRODUCTION
`Apple, Inc., (“Petitioner”) filed a request for an inter partes review of
`claims 1–10, 12–18, 21–31, 33–39, and 42 (the “challenged claims”) of
`U.S. Patent No. 9,038,163 B2 (Ex. 1001, “the ’163 patent”). Paper 1
`(“Pet.”). VirnetX, Inc. (“Patent Owner”) filed a Preliminary Response to the
`Petition. Paper 7 (“Prelim. Resp.”). We instituted an inter partes review of
`the challenged claims of the ’163 patent. Paper 8 (“Dec. Inst.”). Patent
`Owner filed a Patent Owner Response (Paper 17, “PO Resp.”) and Petitioner
`filed a Petitioner Reply (Paper 21, “Pet. Reply”). On February 27, 2018, a
`hearing was held, a transcript of which has been entered into the record.
`Paper 30 (“Tr.”).
`We have jurisdiction under 35 U.S.C. § 6(b). This Final Written
`Decision is issued pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73.
`We base our decision on the preponderance of the evidence. 35 U.S.C.
`§ 316(e); 37 C.F.R. § 42.1(d). Having reviewed the arguments of the parties
`and the supporting evidence, we find that Petitioner has demonstrated by a
`preponderance of the evidence that each of challenged claims, 1–10, 12–18,
`21–31, 33–39, and 42, of the ’163 patent are unpatentable.
`
`A. The ’163 Patent
`The ’163 patent’s specification (the “Specification”) focuses on
`techniques for securely communicating over the Internet based on a protocol
`called the “Tunneled Agile Routing Protocol” or “TARP.” Ex. 1001,
`3:20–23. According to the Specification, TARP allows for secure and
`anonymous communications by using tunneling, an IP address hopping
`scheme where the IP addresses of the end devices and routers participating
`in the system can change over time, and a variety of other security
`
`2
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`techniques. Ex. 1001, 1:38–40, 3:20–6:14. Two sections of the
`Specification––primarily spanning columns 39 to 42 and 49 to 53—are
`directed to techniques for establishing secure communications in response to
`DNS requests specifying a secure destination. See Ex. 1001, 39:26–42:16,
`49:27–53:35. These portions of the Specification discuss the idea of
`modifying a “conventional DNS server” to include additional functionality
`that allows it to support the creation of virtual private networks. See
`Ex. 1001, 40:21–54. According to the Specification, a “modified DNS
`server” (id., 40:25–29) receives a request to look up a network address
`associated with a domain name (id., 39:26–31, 40:4–20, 4:31–49),
`determines whether a secure site has been requested (for example, by
`checking an internal table of sites) (id., 40:33–37, 51:37–41), and then
`performs additional steps to support establishing a “virtual private network”
`with the secure site. See Ex. 1001, 41:22–39, 51:60–66. The Specification
`also describes several optional features of this system, such as using “IP
`hopblocks” to create a VPN or incorporating user authentication. Ex. 1001,
`40:21–30, 49:41–51, 52:53–57. The Specification also describes different
`ways of implementing this “modified DNS server,” including through a
`single standalone DNS server as well as a distributed system incorporating a
`“conventional DNS server function” and a DNS proxy server. Id. at 40:21–
`30.
`
`
`B. Challenged Claims of the ’163 Patent
`Petitioner challenges claims 1–10, 12–18, 21–31, 33–39, and 42 of the
`’163 patent. Challenged claims 1 and 22 are independent. Although similar,
`Claim 1 is directed to a method and claim 22 is directed to a system.
`Claim 1 is illustrative and is reproduced below.
`
`3
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`
`1. A method of connecting a first network device and a second
`network device over a communication network, the method
`comprising:
`
`receiving, from the first network device over the
`communication network, a request to look up a network address
`of the second network device based on an identifier associated
`with the second network device;
`
`evaluating the request to determine whether the identifier
`is
`registered with a name service, connected
`to
`the
`communication network, that facilitates resolving the identifier
`and
`that further facilitates establishing direct encrypted
`communication links;
`
`determining, based on the evaluation, whether the second
`network device is available to communicate through a direct
`encrypted communication link facilitated by the name service;
`and
`based on a determination that the second network device
`
`is available, facilitating the establishment of the direct encrypted
`communication link between the first network device and the
`second network device, the facilitating the establishment of the
`direct encrypted communication link including provisioning the
`first network device or the second network device with one or
`more resources for the direct encrypted communication link,
`
`wherein the established direct encrypted communication
`link carries encrypted data communicated between the first
`network device and the second network device, and the first
`network device is a user device.
`Ex. 1001, 56:9–28.
`
`
`II. DISCUSSION
`
`A. Claim Construction
`In an inter partes review, claim terms in an unexpired patent are given
`their broadest reasonable construction in light of the specification of the
`patent. 37 C.F.R. § 42.100(b); Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct.
`
`4
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`2131, 2144–46 (2016) (upholding the use of the broadest reasonable
`construction as the standard to be applied for claim construction in inter
`partes reviews). “Under a broadest reasonable interpretation, words of the
`claim must be given their plain meaning, unless such meaning is inconsistent
`with the specification and prosecution history.” Trivascular, Inc. v.
`Samuels, 812 F.3d 1056, 1062 (Fed. Cir. 2016). Only those terms that are in
`controversy need be construed, and only to the extent necessary to resolve
`the controversy. Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795,
`803 (Fed. Cir. 1999).
`In our Decision on Institution, we did not find it necessary at that
`point in the proceeding to construe expressly any claim terms or to adopt any
`proposed constructions. See Dec. Inst. 6. Rather, we applied the terms’
`plain and ordinary meanings, as understood by one of ordinary skill in the
`art in light of the specification. Id. Patent Owner did not respond to
`Petitioner’s constructions presented in the Petition. PO Resp. 2. For
`purposes of this Final Written Decision, we continue to apply the plain and
`ordinary meanings of the claim terms.
`B. Level of Ordinary Skill in the Art
`In determining 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). “The importance of resolving the level of ordinary skill in the art
`lies in the necessity of maintaining objectivity in the obviousness inquiry.”
`Ryko Mfg. Co. v. Nu-Star, Inc., 950 F.2d 714, 718 (Fed. Cir. 1991).
`Petitioner argues a person of ordinary skill in the art in the field of the
`’163 patent
`
`5
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`
`would have been someone with a good working knowledge of
`networking protocols, including those employing security
`techniques, as well as computer systems that support these
`protocols and techniques. The person also would be very
`familiar with Internet standards related to communications and
`security, and with a variety of client-server systems and
`technologies. The person would have gained this knowledge
`either through education and training, several years of practical
`working experience, or through a combination of these.
`Pet. 8 (citing Ex. 1003 ¶ 83).
`In Patent Owner’s Response, Patent Owner does not propose directly
`a particular level of ordinary skill in the art with respect to the ’163 patent.
`See generally PO Resp. 1–34. Patent Owner, however, does cite to a
`declaration by Dr. Fabian Monrose concerning what a person of ordinary
`skill in the art would have understood with respect to the prior art. See e.g.,
`PO Resp. 3, 15, 17 (citing Ex. 2002 ¶¶ 36, 57, 52–61, respectively). Dr.
`Monrose’s declaration, however, does not indicate that Dr. Monrose
`reviewed the ’163 patent or the challenged claims. See Ex. 2002 ¶¶ 1–3.
`Based on the evidence of record, including the prior art references, we
`find that a person of ordinary skill in the art in the field of the ’163 patent is
`a person who has a good working knowledge of networking protocols,
`including those employing security techniques, as well as computer systems
`that support these protocols and techniques, and is very familiar with
`Internet standards related to communications and security, with a variety of
`client-server systems and technologies, having gained this knowledge either
`through education and training, several years of practical working
`experience, or through a combination of these.
`C. Alleged Grounds of Unpatentability
`Petitioner alleged a single ground of unpatentability, namely that
`
`6
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`claims 1–10, 12–18, 21–31, 33–39, and 42 of the ’163 patent are
`unpatentable as obvious under 35 U.S.C. § 103 over the combined teachings
`of U.S. Patent No. 6,496,867 (Ex. 1007, “Beser”), “Security Architecture
`for the Internet Protocol,” (Ex. 1008, “RFC 2401”), “SIP: Session Initiation
`Protocol” (Ex. 1013, “RFC 2543”), and knowledge held by a person of
`ordinary skill in the art. Pet. 2. In our Decision on Institution, we instituted
`inter partes review on all the challenged claims alleged unpatentable in the
`Petition based on this ground. Dec. Inst. 20.
`D. Prior Art References
`1. Beser (Ex. 1007)
`Beser describes a tunneling system that establishes an IP (internet
`protocol) tunneling association over a public network such as the Internet
`between two end devices 24 and 26 on private networks. Ex. 1007, 3:60–
`4:19, Abstract, Fig. 1. Beser’s system provides security for “[c]ompanies
`who cannot afford a private network [and] often transfer sensitive corporate
`information over the Internet.” Id. at 1:18–20.
`Figure 1 of Beser follows:
`
`
`
`7
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`
`Figure 1 of Beser’s system depicts public network 12 (for example the
`Internet), network end devices 24 and 26 on private network 20, trusted-
`third-party device 30, and modified edge routers or gateway network devices
`14 and 16. See Ex. 1007, Abstract, 3:60–4:18. Edge routers 14 and 16 route
`packets between Internet or public network 12 and private network 20 that
`include terminating end devices such as 24 and 26. See id. at 4:18–23.
`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. Id. at
`Abstract, Fig. 1, Fig. 6. To begin a process for a secure transaction, at step
`102, requesting device 24 may send to network device 14, as part of its
`request on a protocol layer below an application layer, 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. 1007, 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, or social security number, and a
`public IP address 58 or other similar identifier associated with terminating
`device 26. Ex. 1007, 10:37–11:8, 11:9–12. At step 104, 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
`
`8
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`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. 1007, 11:26–36, Figs. 1, 4, 5.2 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 “IP 58 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
`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
`
`
`2 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. 1007, 3:26–30.
`
`9
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`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.
`2. RFC 2401 (Exhibit 1008)
`RFC 2401 is a request for comments concerning security architecture
`for the Internet protocol. RFC 2401 “specifies the base architecture for
`IPsec compliant systems. The goal of the architecture is to provide various
`security services for traffic at the IP layer.” Ex. 1008, 3. According to RFC
`2401, IPsec provides a “set of security services,” including “access control,
`connectionless integrity, data origin authentication, [and] . . . confidentiality
`(encryption).” Ex. 1008, 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
`
`10
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`
`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.
`
`3. RFC 2543 (Exhibit 1013)
`RFC 2543 is a request for comments concerning the Session Initiation
`Protocol (SIP). RFC 2543 “specifies an Internet standards track protocol for
`the Internet community, and requests discussion and suggestions for
`improvement.” Ex. 1013, 1. RFC 2543 explains that the SIP “is an
`application-layer control (signaling) protocol for creating, modifying and
`terminating sessions with one or more participants. These sessions include
`Internet multimedia conferences, Internet telephone calls and multimedia
`distribution. Members in a session can communicate via multicast or via a
`mesh of unicast relations, or a combination of these.” Id.
`
`RFC 2543 explains that SIP supports five facets of establishing and
`terminating multimedia communications:
`User location: determination of the end system to be
`used for communication;
`User capabilities: determination of the media and
`media parameters to be used;
`User availability: determination of the willingness
`of the called party to engage in communications;
`Call setup: "ringing", establishment of call
`parameters at both called and calling party; [and]
`Call handling: including transfer and termination of
`calls.
`Ex. 1013, 7–8.
`
`
`11
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`D. Obviousness of the Challenged Claims
`1. Independent Claims 1 and 22
`Petitioner contends that independent claims 1 and 22 of the ’163
`patent would have been obvious over the combination of Beser, RFC 2401,
`and RFC 2543. Pet. 41–55. Claims 1 and 22 are markedly similar. Claim 1
`recites a method of connecting two network devices over a communication
`network through a direct encrypted communication link. Ex. 1001, 56:9–28.
`Claim 22 recites a system configured to execute similar steps, but also
`recites some system limitations not found in claim 1. Ex. 1001, 57:43–58:6.
`We consider the limitations claims 1 and 22 have in common below, as well
`as the system limitations found in claim 22.
`a. Preamble of Claim 1
`With respect to the preamble of claim 1, Petitioner relies on Beser to
`teach “connecting a first network device and a second network device over a
`communication network.” Pet. 41–42; Ex. 1007, 8:15–20, 21:52–62, 22:2–
`22; Ex. 1003 ¶¶ 129, 133–134. The process described in Beser begins when
`a user sends a request through the originating end device by, for example,
`initiating a VoIP call. Ex. 1007, 10:2–4, 10:22–36, 10:57–66; Ex. 1003
`¶ 133. The request is processed by a third-party network device, which, with
`the help of the first and second network devices, establishes a private
`tunneling association between the end devices, enabling the originating end
`device to connect to and communicate with the terminating end device.
`Ex. 1007, 8:15–20, 14:51–67, 19:21–37, 23:15–25; Ex. 1003 ¶¶ 133–134.
`Patent Owner does not contest specifically Petitioner’s evidence with
`respect to the preamble. See PO Resp. 2–6. Rather, Patent Owner
`acknowledges that Beser involves initiating a tunneling association between
`
`12
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`an originating end and a terminating end facilitated by an intermediary,
`trusted-third-party network device. PO Resp. 3.
`Based on this evidence, Petitioner has shown sufficiently that Beser’s
`user sending a request to initiate a VoIP call from an originating device
`through a network to connect with an end device teaches or suggest the
`preamble’s “connecting a first network device and a second network device
`over a communication network.”
`b. “receiving, from the first network device…, a request
`to look up a network address of the second network
`device based on an identifier associated with the
`second network device”
`With respect to the limitation “receiving, from the first network
`device…, a request to look up a network address of the second network
`device based on an identifier associated with the second network device,”
`Petitioner relies on Beser originating end device (“first network device”)
`sending a request to initiate a VoIP tunneling association with a terminating
`end device (“second network device”). Pet. 42–43; Ex. 1007, 7:64–8:1,
`9:64–10:41; Ex. 1003 ¶¶ 168, 172. This request, Petitioner explains,
`contains a unique identifier associated with the terminating end device (“an
`identifier associated with the second network device”). Id.; Ex. 1007, 8:1–3,
`10:37–11:8; Ex. 1003 ¶¶ 173–174. Petitioner further explains that Beser’s
`unique identifier can be a domain name or a VoIP phone number (Ex. 1007,
`10:37–42, 10:55–11:5), and the trusted third-party network device that
`processes the request can be a domain name server (id., 4:9–11, 11:33–36).
`Pet. 43. Petitioner notes that the Specification describes the use of a
`“domain name” as an identifier in a DNS (Domain Name Server) request.
`Id.; see Ex. 1001, 39:34–40, 40:34–40; Ex. 1003 ¶¶ 131–132.
`
`13
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`
`Patent Owner argues that Beser’s request is to initiate a tunneling
`connection, and “is not ‘a request to look up an internet protocol (IP)
`address’ of the terminating end device based on a domain name associated
`with the terminating end device.” PO Resp. 6–7 (citing Ex. 2002 ¶ 41).
`Patent Owner argues that “Beser 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,” because “there is no ‘look up’ of the
`private IP address for terminating device 26.” Id. at 8–9 (citing Ex. 1007,
`11:26–32, 12:2–4; Ex. 2002 ¶¶ 43–44). The private IP address for
`terminating device 26, Patent Owner argues, is simply assigned to the
`terminating device. Id. at 8.
`Beser, however, states expressly that “the trusted-third-party network
`device 30 is . . . a domain name server.” Ex. 1007, 11:33–34. As Dr.
`Tamassia testifies, typical domain name server functionality includes
`looking up IP addresses to assign them a unique identifier. See Ex. 1003 ¶¶
`95–101. In Beser, the tunneling request sent by originating device 24 is a
`“request to look up a network address” because in response to receiving the
`request, the Beser trusted device 30 looks up at least two IP addresses.3
`First, it consults an internal database of registered devices to look up the IP
`address of second network device 16 that is associated with the unique
`identifier. Ex. 1007, 11:45–58. Second, it looks up a private IP address for
`terminating device 26 by sending a message to network device 16 requesting
`
`
`3 Beser also discloses other unique identifiers for a look up related to
`terminating device 26, including, inter alia, a “domain name” and a
`“previously assigned public IP 58 address.” Ex. 1007, 10:41–11:2.
`
`14
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`the address. Ex. 1007, 9:29–30, 12:16–19, 14:14–27, Figs. 6 and 9. As a
`result of this process, originating device 24 receives an IP address for
`terminating device 26. Ex. 1007, 21:48–52.
`Patent Owner’s argument that the private address for terminating
`device 26 is simply “assigned” without involving a “look up” is not
`persuasive because the trusted device 30 “looks up” the IP address when it
`sends a message to network device 16 requesting a private IP address.
`Ex. 1007, Fig. 9 (packets 164 & 166), 13:33–48, 13:66–14:18. Moreover,
`second device 16 does not simply “assign” an IP address —it looks one up
`by selecting an unused address out of a pool of IP addresses. Ex. 1007,
`13:49–64.
`Based on this evidence, Petitioner has shown sufficiently that Beser’s
`user sending a request to initiate a tunneling association from an originating
`device through a network to connect with an end device teaches or suggests
`the recited limitation “receiving, from the first network device…, a request
`to look up a network address of the second network device based on an
`identifier associated with the second network device,”
`c. “evaluating the request to determine whether the
`identifier is registered with a name service,” that
`“facilitates resolving the identifier and that further
`facilitates establishing direct encrypted
`communication links”
`With respect to the limitation “evaluating the request to determine
`whether the identifier is registered with a name service,” that “facilitates
`resolving the identifier and that further facilitates establishing direct
`encrypted communication links,” Petitioner relies on Beser’s explanation
`that a trusted-third-party network device can be a domain name server that
`functions according to industry standards (Pet. 45; Ex. 1007, 4:55–63,
`
`15
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`11:32–36; Ex. 1003 ¶¶ 158–161), but is modified to maintain a database of
`subscribers, (Ex. 1007, 11:48–52). Beser’s database, Petitioner explains,
`correlates each subscriber’s registered unique identifier to “the IP 58 address
`of a particular second network device 16” and may also include “public IP
`58 addresses for the terminating telephony device 26.” Pet. 45; Ex. 1007,
`11:48–52; 8:65–9:1, 11:26–44; Ex. 1003 ¶¶ 162–165.
`Petitioner argues that Beser teaches, in response to each tunneling
`request, the trusted-third-party network device parses the request to evaluate
`and determine whether the unique identifier is listed in its internal database
`of registered users or devices (“evaluating. . . whether the identifier is
`registered”). Pet. 45; Ex. 1007, 11:30–36, 11:45–58; Ex. 1003 ¶ 165.
`Petitioner notes the Specification describes a similar evaluation by checking
`a domain name against an internal table of secure sites. Pet. 45; see Ex.
`1001, 40:33–37. Petitioner explains that if the unique identifier is registered
`as a subscriber, the trusted-third-party device 30 will negotiate with the first
`and second network devices to establish an IP tunnel between those network
`devices. Pet. 45; Ex. 1007, 9:6–11, 11:59–62; 9:26–30, 11:9–44; Ex. 1003
`¶¶ 165–166, 178–180.
`Patent Owner argues that before assigning the public IP address of
`device 16 to the unique identifier, Beser never checks whether the identifier
`is registered with the third party device 30. PO Resp. 11 (citing Ex. 1007,
`11:26–32, 11:45–57). Moreover, Patent Owner argues, Beser never suggests
`that this data structure is looked up when the tunnel request is received by
`device 30. Id. (citing Ex. 2002 ¶ 44; Ex. 1007, 11:45–57).
`Beser’s trusted third-party network device, however, includes a
`modified domain name server that maintains a database of subscribers.
`
`16
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`Ex. 1007, 4:55–63, 11:32–36, 11:48–52; Ex. 1003 ¶¶ 158–161. The
`database maps each subscriber’s unique identifier to IP addresses including
`associated IP addresses for the second network device and terminating
`device. Ex. 1007, 11:48–52; Ex. 1003 ¶¶ 162–165. Upon receipt of a
`tunneling request, the trusted-third-party network device searches the
`database for the entry that matches a registered unique identifier. Ex. 1007,
`11:45–58. If the unique identifier is registered—matches an entry—as a
`subscriber of the modified domain name server, the trusted-third-party
`network device negotiates to establish a tunnel between those network
`devices using the IP addresses. Ex. 1007, 9:6–11, 11:59–62, 9:26–30, 11:9–
`36; Ex. 1003 ¶¶ 165–166, 178–180.
`Based on this evidence, Petitioner has shown sufficiently that Beser
`teaches or suggests the recited limitation “evaluating the request to
`determine whether the identifier is registered with a name service,” that
`“facilitates resolving the identifier and that further facilitates establishing
`direct encrypted communication links.”
`d. “determining . . . whether the second network device
`is available to communicate through a direct
`encrypted communication link facilitated by the name
`service”
`With respect to the limitation “determining, based on the evaluation,
`whether the second network device is available to communicate through a
`direct encrypted communication link facilitated by the name service,”
`Petitioner relies on Beser combined with RFC 2401 and RFC 2543’s
`protocol for establishing a VoIP connection. Pet. 46. Petitioner asserts that
`Beser suggests this configuration by describing an embodiment where a
`tunneling request is a VoIP request having a system compatible with IETF
`
`17
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`(Internet Engineering Task Force) standards. Pet. 46; Ex. 1007, 4:55–62,
`10:2–4. In this configuration, Petitioner explains, the originating and
`terminating devices are SIP user agents, and the first and second network
`devices are SIP proxy servers. Id.; Ex. 1003 ¶ 256. Petitioner asserts that
`when the Beser originating device initiates an IP tunnel for a VoIP call, it
`generates an INVITE message per RFC 2543, which then serves as a VOIP
`request to initiate the VoIP association. Pet. 46; Ex. 1007, 10:2–6.
`In this configuration, Petitioner explains, after the trusted-third-party
`network device determined the unique identifier was registered, it would
`look up the public IP address of the second network device. Pet. 47;
`Ex. 1003 ¶¶ 258–260. The VoIP request (in Beser, the INVITE message)
`would then be sent to the second network device. Id. Petitioner asserts that
`this message could be sent by the trusted-third-party network device, as
`shown in Beser Figure 9, or it could be sent by the first network device, as
`shown in Figure 14. Id. Petitioner asserts that before selecting a private IP
`address for the terminating device, the second network device would process
`the INVITE message according RFC 2543. Pet. 47; Ex. 1003 ¶ 261. The
`second network device would then forward the message to the terminating
`end device, causing it to ring. Id.; Ex. 1013, 16, 75. If the user answered the
`phone, Petitioner asserts, it would return a success status message to the
`second network device as taught by RFC 2543. Pet. 47; Ex. 1013, 76, 92–
`94.
`
`Petitioner argues that in the combined system of Beser, RFC 2401,
`and RFC 2543, a device that is registered with device 30 supports
`“encrypted communication links” (i.e., it supports Beser’s IP tunnel
`configured to provide end-to-end encryption), and thus, if the user answers
`
`18
`
`
`
`IPR2017-00337
`Patent 9,038,163 B2
`
`the phone, that device is available for such a link. Pet. 48; see Ex. 1003
`¶¶ 237–241.
`In its Response, Patent Owner does not respond specifically to
`Petitioner’s evidence with respect to this limitation. See generally PO
`Resp. 2–18.
`
`Based on this evidence, Petitioner has shown sufficiently that Beser’s
`tunneling request to initiate a VoIP association sent to a second network
`device by a trusted-third-party network device, where the second network
`device forwards the message to the terminating end device, and if answered,
`return a success status message to the second network device, teaches or
`suggests the recited limitation “determining, based on the evaluation,
`whether the second network device is available to communicate through a
`direct encrypted communication link facilitated by the name service.”
`e. “facilitating the establishment of the direct encrypted
`communication link between the first network device
`and the second network device”
`With respect to t
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
