Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper 8
`Entered: Oct. 1, 2015
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`
`
`
`
`
`
`
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`Tel: 571-272-7822
`
`Paper 8
`Entered: Oct. 1, 2015
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`
`
`
`
`
`
`
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`I. INTRODUCTION
`A. Background
`Petitioner, Apple Inc., filed a Petition (Paper 1, “Pet.”) requesting an
`inter partes review of claims 1–30 (the “challenged claims”) of U.S. Patent
`No. 8,560,705 B2 (Ex. 1050, “the ’705 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 ’705 patent “has never been asserted
`against Petitioner in litigation.” Pet. 1. Patent Owner indicates that the ’705
`patent “and/or” related patents are involved in several proceedings in the
`United States District Court for the Eastern District of Texas.1 Paper 5, 12–
`
`
`1 In the future, Petitioner is advised that referring to “numerous lawsuits,”
`without specifically identifying the court in which the lawsuit is taking place
`and other information necessary to identify the proceeding may be
`considered a violation of 37 C.F.R. § 42.8. See Pet. 6–7. Similarly, Patent
`Owner is advised to be specific in addressing whether the challenged patent
`
`2
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`13. Petitioner filed another petition seeking inter partes review of the ’705
`patent—IPR2015-00871. Pet. 2. In addition, many other inter partes review
`and inter partes reexamination proceedings challenging related patents are
`currently, or have been recently, before the Office. See Paper 5, 2–10.
`
`C. The Asserted Grounds of Unpatentability
`Petitioner contends, under 35 U.S.C. § 103, that claims 1–23 and 25–
`30 of the ’705 patent are unpatentable based on the combination of Beser2
`and RFC 24013, and that claim 24 is unpatentable based on the combination
`of Beser, RFC 2401, and Brand4. Petitioner also provides testimony from
`Dr. Roberto Tamassia. Ex. 1005.
`
`D. The ’705 Patent
`The ’705 patent describes secure methods for communicating over the
`Internet. Ex. 1050, 9:41–46. Specifically, the ’705 patent describes “the
`automatic creation of a virtual private network (VPN) in response to a
`domain-name server look-up function.” Id. at 39:4–6. This automatic
`creation employs a modified Domain Name Server, which may include a
`conventional Domain Name Server (DNS):
`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
`
`is actually the subject of the enumerated related litigation. See Paper 5, 12–
`13.
`2 U.S. Patent No. 6,496,867 B1 (Ex. 1007).
`3 S. Kent and R. Atkinson, Security Architecture for the Internet Protocol,
`Request for Comments: 2401, BBN Corp., November 1998 (Ex. 1008).
`4 U.S. Patent No. 5,237,566 (Ex. 1012).
`
`3
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`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:7–13.
`
`The modified DNS server may include both a conventional
`DNS and a DNS proxy. Id. at 39:67–40:2. 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:6–16. 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:32–33. 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:12–16. 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:19–25.
`The VPN is “preferably implemented using the IP address
`‘hopping’ features,” (changing IP addresses based upon an agreed
`upon algorithm) described elsewhere in the ’705 patent, “such that the
`true identity of the two nodes cannot be determined even if packets
`during the communication are intercepted.” Id. at 39:52–56.
`
`4
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`E. Illustrative Challenged Claim 1
`Claims 1 and 16 of the ’705 patent are independent and of similar
`scope. Claim 1, illustrative of the challenged claims, follows:
`1. A client device comprising:
`
`(a) memory configured and arranged to facilitate a
`connection of the client device with a target device over a
`secure communication link created based on
`
`
`(i) interception of a request, generated by the
`client device, to look up an internet protocol (IP) address
`of the target device based on a domain name associated
`with the target device, and
`
`
`(ii) a determination as a result of the request that
`the target device is a device with which a secure
`communication link can be established;
`
`(b) an application program configured and arranged so
`as to allow participation in audio/video communications
`with the target device over the secure communication link
`once the secure communication link is established; and
`
`(c) a signal processing configuration arranged to
`execute the application program.
`Ex. 1003, 55:52–65.
`
`II. ANALYSIS
`A. Claim Construction
`“[T]he PTO give[s] claims [in an unexpired patent] their broadest
`reasonable construction.” In re Cuozzo Speed Techs., LLC, 793 F.3d 1268,
`1277 (Fed. Cir. 2015). Under this standard, the Board interprets claims in
`light of the patent specification. 37 C.F.R. § 42.100(b). Under “the best
`practices for claim construction,” a claim term generally carries its
`“‘ordinary and customary meaning’”–– “‘the meaning that the term would
`have to a person of ordinary skill in the art in question. . . . in view of the
`specification.’” In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir.
`
`5
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`2007) (quoting Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en
`banc)).
`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. For the purposes of this
`Decision, and on this record, we determine that no claim term 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).
`
`B. Prior Art Printed Publication Status of RFC 2401
`Patent Owner asserts that Petitioner fails to show that RFC 2401 (Ex.
`1008) is prior art “because [Petitioner] fails to establish (1) the alleged
`publication date, and (2) that RFC 2401 would have been sufficiently
`accessible to the public interested in the art on its alleged publication date,”
`November 1998 (the date recited on each of its pages). See Prelim. Resp. 6;
`Ex. 1008. On this basis, according to Patent Owner, Petitioner cannot rely
`upon RFC 2401 as prior art; therefore, Petitioner has not satisfied its burden
`of showing a reasonable likelihood of prevailing with respect to any
`challenged claim of the ’705 patent. Prelim Resp. 2–6.
`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
`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
`
`6
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`“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.
`On this record, Petitioner has made a threshold showing that RFC
`2401 constitutes a prior art printed publication.5 Accordingly, we consider
`the disclosure of RFC 2401 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.
`
`
`
`
`5 To the extent that Patent Owner objects to the admissibility of this
`evidence, it will have the opportunity, after trial is instituted, to enter any
`objections to evidence. 37 C.F.R. § 42.64(b)(1). To the extent that Patent
`Owner continues to assert that Petitioner has not met its burden of showing
`that RFC 2401 is a “printed publication,” it will have the opportunity to
`make this argument in its Patent Owner Response.
`
`
`7
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`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
`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
`
`8
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`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 the 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).
`
`3) Claims 1 and 16
`Petitioner asserts that Beser’s “non-encrypted streaming audio/video
`example” (Pet. 28) encompasses almost all of the limitations of claims 1 and
`16, but does not disclose explicitly all elements of the recited determining
`
`9
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`step and the related “secure communications link,” under a claim
`construction that assumes that the claimed link requires encryption for data
`traffic on the link. See id. at 34–42. Specifically, Petitioner argues that the
`claimed client device reads on Beser’s originating end device, and that the
`claimed target device reads on Beser’s terminating end device. Id. at 34–35.
`Petitioner explains that Beser’s trusted-third-party network device 30
`negotiates private IP addresses with first and second network devices based
`on a request that includes a unique domain name for the claimed target
`device. See id. at 34–37. For example, according to Petitioner, Beser’s
`“trusted-third-party network device [30] . . . with the help of the first [14]
`and second [16] network devices, establishes a private tunneling
`association” by processing requests for access to a WebTV source or for
`initiating a VoIP call. Id. at 34 (citing Ex. 1007, 4:43–54, 7:64–66, 10:22–
`36, 10:55–66; Ex. 1005 ¶¶ 354, 358, 383).
`Petitioner contends that Beser’s negotiating devices (14, 30, and 16,
`see Ex. 1007, Fig. 9), as modified by RFC 2401, thereby facilitate a
`connection with terminating end device 26 over a secure network created in
`response to interception of a request to look up an internet address based on
`a domain name for end device 26, and determines as a result that end device
`26 is a device with which a secure communication link can be established, as
`claim 1 requires. See id. at 34–39; Ex. 1007, Figs. 1, 4, 5. According
`further to Petitioner, it would have been obvious to a person of ordinary skill
`in the art to provide “end-to-end” encryption of the traffic being sent in
`Beser using the teachings of RFC 2401. Pet. 29–30.
`Petitioner contends that “[i]n any scenario, if the unique identifier
`[domain name] is not registered, the trusted-third-party network device
`
`10
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`would not negotiate an IP tunnel. Id. at 39 (citing Ex. 1005 ¶ 363). As a
`consequence, “Beser shows a ‘determination’ as specified in claims 1 and
`16.” Id. (emphasis omitted). Petitioner argues that the combination of Beser
`and RFC 2401 would have rendered obvious the determination step
`“[b]ecause in this [modified] configuration all IP tunnels would have been
`encrypted, [such that] the determination that the terminating device can
`establish an IP tunnel is a determination that it accepts encrypted
`communications (“that a secure communication link can be established”).
`Id. at 39 (citing Ex. 1007, 1:54–56, 11:26–58; Ex. 1005 ¶¶ 361–63, 368,
`431, 433, 436–37).
`Petitioner also contends that the combination of Beser and RFC 2401
`teaches or suggests the remaining elements of claims 1 and 16, including the
`recited memory, application for “allow[ing] participation in audio/video
`communications over the secure communication link,” and processing
`configuration for the application. See id. at 40–42.
`
`
`
`i) Rationale to Combine
`Petitioner argues 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. 30 (citing Ex. 1007, 1:54–56; Ex. 1005 ¶¶ 383–
`85, 395). 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 30–31 (citing Ex. 1007, 1:54–56, 4:55–5:2,
`
`11
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`11:22–25, 18:2–5; Ex. 1005 ¶¶ 320–21, 323, 421–24, 426–28, 432–33, 436–
`41). Petitioner contends that a person of ordinary skill would have
`recognized that IPsec readily could have been integrated into Beser’s
`systems. Id. at 31–32 (citing Ex. 1005 ¶¶ 431–32, 436–38). Petitioner also
`contends that basic configurations of the two disclosed systems in Beser and
`RFC 2401 are similar. Id. (citing Ex. 1005 ¶¶ 434–35); Ex. 1005 ¶ 435
`(characterizing Beser at Figure 1 and RFC 2401 at page 25 as each
`disclosing “ a configuration in which edge routers are connected to private
`networks and communicate over a public network”).
`Patent Owner argues that Beser and RFC 2401 would not have been
`combined as asserted by Petitioner. Prelim. Resp. 15–21. According to
`Patent Owner, Beser teaches away from using the IPsec protocol of RFC
`2401 for audio or video data by explaining that streaming data flows, such as
`multimedia, require a great deal of computing power to encrypt or decrypt,
`and the “strain of such computations ‘may result in jitter, delay, or the loss
`of some packets.’” Id. at 16 (quoting Ex. 1007, 1:64–65). Patent Owner
`also contends that Beser teaches “hid[ing network] addresses within the
`payload of tunneled messages. . . . without increasing computational
`burden.” Id. at 17 (citing Ex. 1007, 2:36–40, 2:43–3:14, 9:49–51.) Patent
`Owner adds that Beser “also teaches that encryption does not deter a
`determined hacker from deducing source and identity information, and so,
`once the tunnel is established, Beser eschews encryption in favor of hiding
`the identities within the tunnel” and, thus, adding encryption would
`“contravene Beser’s express objective of increasing security without
`increasing computational burden.” Id. at 18–19. Therefore, Patent Owner
`concludes that “one of ordinary skill in the art would understand that Beser
`
`12
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`is directed to providing a method for securing communications other than
`encryption.” Id. at 17 (citing Ex. 2009 ¶ 56).
`At this point in the proceeding, the record does not indicate that Beser
`teaches away from adding encryption to its system to allow “participation in
`audio/video communications” as claims 1 and 16 recite. Although Beser
`recognizes that the use of encryption may cause challenges, it also suggests
`that such problems may be overcome by providing more computer power
`and/or less quality. See Ex. 1007, 1:60–63; Ex. 1005 ¶¶ 426–28. Beser
`specifically characterizes some prior art systems as creating “security
`problems by preventing certain types of encryption from being used.” Ex.
`1007, 2:23–24. In other words, Beser does not indicate on this record, as
`Patent Owner argues, that a determined hacker could deduce source and
`identity information if Beser’s address-hiding scheme includes encryption of
`audio/video data encompassed by the claims.
`Petitioner relies on similar rationale supported by Beser: “Indeed,
`several passages of Beser plainly indicate that encryption should be used and
`criticize prior art techniques that prevent use of end-to-end encryption.” Pet.
`32 (citing Ex. 1007 at 2:22–27, 11:22–25, 18:2–5, 20:11–14). Petitioner
`also contends that Beser suggests tradeoffs: “Moreover, the implementation
`challenges that Beser identifies in using encryption in data streaming
`applications would have been seen by a person of ordinary skill as
`implicating simple trade-offs – increasing or limiting the quality of the
`streaming video or audio data, or using less or more powerful equipment.”
`Id. at 32–33 (citing Ex. 1005 ¶¶ 426–28).
`On this limited record, Petitioner sets forth a persuasive rationale that
`a person of ordinary skill would have found it obvious to combine the
`
`13
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`teachings of RFC 2401 with Beser to encrypt audio/video data on a secure
`tunnel and determine that requested target devices would have been
`available for such secure communications.
`
`
`
`ii) Conclusion
`Based on the foregoing discussion, we determine that Petitioner
`demonstrates a reasonable likelihood of prevailing in its challenge that the
`combination of Beser and RFC 2401 would have rendered claims 1 and 16
`obvious.
`4) Claim 8
`
`Claim 8 depends from claim 3, and further specifies that the
`establishment of the secure communication link “is based on the
`determination being made by a proxy module that the target device is a
`device with which a secure communication link can be established when the
`domain name corresponds to a target device identified in a DNS lookup
`table.” Similar to its showing for claim 1 and addressing claim 8, Petitioner
`contends that Beser’s “trusted-third-party network device negotiates with the
`first and second network devices to establish a private IP tunnel. Pet. 50
`(citing Ex. 1007, 9:6–11, 9:26–30, 11:9–44; Ex. 1005, ¶¶ 368, 371, 373–
`378). Petitioner contends further that Beser’s negotiation and other DNS
`look-up functions are similar to functions performed by DNS proxy 2610
`and DNS server 2609 as described in the ’705 patent, and that the latter two
`may be combined “into a single server for convenience.” Id. (quoting Ex.
`1050, 40:44–46).
`
`Patent Owner argues in response that “Petitioner never shows nor
`explains how associating a unique identifier with the address of a second
`network device 16—which Petitioner never alleges is the claimed ‘target
`
`14
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`device’—discloses ‘the determination being made by a proxy module . . .
`when the domain name corresponds to a target device identified in a DNS
`lookup table.’” Prelim. Resp. 22–23 (quoting Pet. 50–51). Patent Owner
`also contends correctly that “Petitioner has repeatedly alleged that the
`terminating end device 26 is the claimed ‘target device.’” Id. at 23 (citing
`Pet. 34).
`Patent Owner’s arguments are not persuasive because, as explained
`further below, Beser discloses associating at least three IP addresses with the
`unique domain name, not merely the IP address of second device 16. As
`discussed above in connection with claim 1, Beser also discloses that
`trusted-third-party device 30 may be a DNS––on this record, a domain name
`server that provides database look-up (mapping) based on unique domain
`names, rendering a lookup table as an implicit or obvious known data
`structure. See Ex. 1007, 11:32–36; Ex. 1005 ¶¶ 341–46, 365–66; Ex. 1050,
`39:1–3 (describing a conventional DNS). For example, Beser discloses that
`such a DNS database may include “public IP 58 addresses for the
`terminating device 26. Many data structures that are known to those skilled
`in the art are possible for the association of the unique identifiers [for
`terminating device 26] and IP addresses for the second network devices 16.”
`Ex. 1007, 11:50–55. Beser also discloses that DNS 30 may be “distributed
`over several physical locations.” Id. at 11:36.
`In addition to that public IP address for end device 26, Beser also
`employs DNS 30 (working with devices 14 and 16) to associate the unique
`domain name of end device 26 with a private IP address for it. See id. at
`10:27–41, 11:20–12:19. In other words, on this record, Beser discloses or at
`least suggests, a proxy module and look up table as set forth in claim 8,
`
`15
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`wherein DNS 30 works with first and second network devices 14 and 16 as
`a proxy module to match a unique domain name for target device 26 and
`associate it with one or more of three IP addresses: a public address for
`second device 16 (which is associated with target device 26), a private
`address for target device 26, and a public address for target device 26. See
`id. at 9:35–37, 11:48–58.
`Based on the foregoing discussion, we determine that Petitioner
`demonstrates a reasonable likelihood of prevailing in challenging claim 8 as
`obvious based on the combination of Beser and RFC 2401.
`4) Claims 13 and 28
`
`Claims 13 and 28 depend respectively from claims 1 and 16, and
`require the target device to be a “server.” Petitioner relies on Beser’s
`disclosure that terminating end device 26 (i.e., the claimed target device)
`may be a multimedia device, such as a Web-TV set and decoder, an
`interactive video-game player, or a personal computer. See Pet. at 54 (citing
`Ex. 1007, 4:47–49). Petitioner relies further on Dr. Tamassia and contends
`that skilled artisans would have recognized that “[a] person of ordinary skill
`in the art would understand that a Web-TV device or a multimedia
`application would be used by connecting to and downloading content from a
`server.” Id. (citing Ex. 1005 ¶ 327). Petitioner also relies on Beser’s
`disclosure that the terminating end device is associated with a domain name,
`“which would suggest to a person of ordinary skill in the art that the
`terminating end device could be a server.” Id. (citing Ex. 1005 ¶¶ 160–66;
`Ex. 1007, 10:39–41, 10:55–11:5).
`
`16
`
`
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`Patent Owner contends that Petitioner’s showing is deficient because
`Petitioner fails to explain or show that all Web-TV and
`multimedia applications would have necessitated connecting to
`and downloading from a server. Moreover, that the terminating
`device 26 (the alleged target device) can connect to a server
`does not disclose, inherently or otherwise, that the terminating
`device itself is a server.
`Prelim. Resp. 25.
`On this record, Patent Owner’s argument is not persuasive because
`Petitioner does not rely merely on a target device connecting to a server. See
`id. As Petitioner contends, Beser describes terminating end devices with
`domain names associated therewith. Pet. 54 (citing Ex. 1007, 10:37–41,
`10:55–11:5). Dr. Tamassia generally describes Beser’s DNS as functioning
`in a known manner and providing services that track the location of
`“resources or computers” from clients by looking up address information.
`Ex. 1005 ¶ 342. Moreover, Beser explicitly states that “‘the ends of the data
`flow may be other types of network devices,’” including a wide variety
`devices, and “the present invention is not restricted to telephony or
`multimedia devices.” See Pet. 53–54 (quoting Ex. 1007, 4:53–54, citing
`4:14–18, 43–54). As Patent Owner acknowledges, Beser discloses servers.
`Prelim. Resp. 25–26. Claims 13 and 28 do not specify any special function
`for the claimed servers.
`Based on the foregoing discussion, we determine that Petitioner
`demonstrates a reasonable likelihood of prevailing in its challenge that the
`combination of Beser and RFC 2401 would have rendered claims 13 and 28
`obvious.
`
`17
`
`
`
`
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`5) Claim 24
`
`Claim 24 depends from claim 16, a method claim, and further
`specifies “wherein the secure communication link [of claim 16] is an
`unmodulated transmission link.” Petitioner relies on the combination of
`Beser, RFC 2401, and Brand, and the testimony of Dr. Tamassia, in its
`obviousness challenge to claim 24. See Pet. 54–55 (citing Ex. 1005 ¶¶ 444,
`455).
`Patent Owner does not address specifically the challenge to claim 24,
`but contends that “[t]he meaning of ‘modulated transmission link’ and
`‘unmodulated transmission’ link are apparent to one skilled in the art
`without construction.” Prelim. Resp. 56. Patent Owner also contends that
`an “unmodulated transmission link” is “a transmission link for transmitting
`data that is not encoded by varying a carrier signal.” Id. at 57.
`On this limited record, Petitioner sufficiently shows that skilled
`artisans would have recognized that Beser’s secure link, as modified by the
`teachings of RFC 2401 and Brand, would have transmitted, in a predictable
`manner, either or both well-known data transmission type(s) as set forth in
`Patent Owner’s claim construction noted above: encoded data that either 1)
`varies, or 2) does not vary, a carrier signal.
`Based on the foregoing discussion, we determine that Petitioner
`demonstrates a reasonable likelihood of prevailing in its challenge to claims
`13 and 28 as obvious based on Beser, RFC 2401, and Brand.
`III. CONCLUSION
`For the foregoing reasons, we determine that the information
`presented in the Petition establishes that there is a reasonable likelihood that
`
`18
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`Petitioner would prevail with respect to challenged claims 1–30 of the ’705
`patent.
`Any discussion of facts in this decision are made only for the purposes
`of institution and are not dispositive of any issue related to any ground on
`which we institute review. The Board has not made a final determination on
`the patentability of any challenged claims. The Board’s final determination
`will be based on the record as fully developed during trial.
`
`IV. ORDER
`
`Accordingly, it is
`ORDERED that pursuant to 35 U.S.C. § 314, we institute an inter
`partes review of 1) claims 1–23 and 25–30 of the ’705 patent as obvious
`over Beser and RFC 2401, and 2) claim 24 of the ’705 patent as obvious
`over Beser, RFC 2401, and Brand;
`FURTHER ORDERED that pursuant to 35 U.S.C. § 314(c) and
`37 C.F.R. § 42.4, notice is hereby given of the institution of a trial; and,
`FURTHER ORDERED that the trial is limited to the grounds
`identified above.
`
`
`
`
`
`
`
`19
`
`
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`
`PETITIONER:
`
`Jeffrey P. Kushan
`Thomas A. Broughan, III
`SIDLEY AUSTIN LLP
`jkushan@sidley.com
`tbroughan@sidley.com
`iprnotices@sidley.com
`
`
`
`PATENT OWNER:
`
`Joseph E. Palys
`Naveen Modi
`PAUL HASTINGS LLP
`josephpalys@paulhastings.com
`naveenmodi@paulhastings.com
`
`Jason Stach
`FINNEGAN, HENDERSON, FARABOW,
`GARRETT & DUNNER, L.L.P.
`jason.stach@finnegan.com
`
`
`
`20
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
