`571-272-7822
`
` Paper No. 8
`Entered: September 11, 2015
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`____________
`
`Case IPR2015-00810
`Patent 8,868,705 B2
`____________
`
`
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`ANDERSON, Administrative Patent Judge.
`
`DECISION
`
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`
`
`
`I. INTRODUCTION
`
`Apple Inc. (“Petitioner”) filed a Petition (Paper 1, “Pet.”) pursuant to
`
`35 U.S.C. §§ 311–319 to institute an inter partes review of claims 1–34 of
`
`U.S. Patent No. 8,868,705 B2 (Ex. 1001, “the ’705 patent”). VirnetX Inc.
`
`(“Patent Owner”)1 filed a Preliminary Response. Paper 6 (“Prelim. Resp.”).
`
`We have jurisdiction under 35 U.S.C. § 314.
`
`For the reasons explained below, we institute an inter partes review of
`
`claims 1–34 of the ’705 patent. We have not yet made a final determination
`
`with respect to the patentability of any claim.
`
`A. Related Matters
`
`Petitioner fails to identify directly or generally any lawsuits where the
`
`’705 patent has been asserted against it.2 Patent Owner’s has asserted the
`
`’705 patent, or patents in the same family as the application which resulted
`
`in the ’705 patent, against Petitioner in four different lawsuits. Paper 5, 12–
`
`13.3
`
`
`1 The Petition also names Science Application International Corporation as
`Patent Owner. However, the Patent Owner Preliminary Response names
`only VirnetX.
`2 Petitioner is advised that its failure to identify any judicial or all
`administrative matters relating to the ’705 patent which would affect or be
`affected by a decision here may be considered a violation of 37 C.F.R.
`§ 42.8. See Pet. 6–7.
`3 Patent Owner is advised to be specific in addressing whether the
`challenged patent is actually the subject of the enumerated related litigation
`instead of stating the ’705 patent “and/or other patents that stem from the
`same applications that led to the ’705 patent.” In the future, general
`statements such as this may be considered a violation of 37 C.F.R. § 42.8.
`See Paper 5, 12–13.
`
`
`
`
`2
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`
`Petitioner also filed another petition seeking inter partes review of the
`
`’705 patent—IPR2015-00811. Pet. 2.4 In addition, many other inter partes
`
`review and inter partes reexamination proceedings challenging related
`
`patents are currently, or have been recently, before the Office. Paper 5, 3–
`
`10.
`
`B. The ’705 Patent
`
`The ’705 patent describes a system and method for transparently
`
`creating an encrypted communications channel between a client device and a
`
`target device. Ex. 1001, Abstract, Figs. 26, 27 (elements 2601, 2604).
`
`Secure communication is based on a protocol called the “Tunneled Agile
`
`Routing Protocol” or “TARP.” Id. at 3:16–19. Once the encrypted
`
`communications channel is created, the devices are configured to allow
`
`encrypted communications between themselves over the encrypted
`
`communications channel. Id. at 40:66–41:9.
`
`
`4 Again, Petitioner failed to meet its obligation under 37 C.F.R. § 42.8.
`There are numerous other proceedings regarding related patents which may
`be affected by the decision in this proceeding which are not listed in the
`Petition. See Paper 5.
`
`
`
`3
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`
`Figure 26 is reproduced below.
`
`
`
`Referring to Figure 26, user’s computer 2601 is a conventional client, e.g., a
`
`web browser. Ex. 1001, 39:58–60. Gatekeeper server 2603 is interposed
`
`between modified Domain Name Server (“DNS”) 2602 and secure target
`
`site 2604. Id. at 39:62–66. The DNS includes both conventional DNS
`
`server function 2609 and DNS proxy 2610. Id. Conventional IP protocols
`
`allow access to unsecure target site 2611. Id. at 39:66–67.
`
`In one described embodiment, establishing the encrypted
`
`communications channel includes intercepting from the client device a
`
`request to look up an Internet Protocol (IP) address corresponding to a
`
`domain name associated with the target device. Ex. 1001, 40:1–19. It
`
`further includes determining whether the request to look up the IP address
`
`corresponds to a device that accepts an encrypted channel connection with
`
`
`
`4
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`the client device. Id. at 40:1–29. Gatekeeper 2603 facilitates and allocates
`
`the exchange of information for secure communication, such as using
`
`“hopped” IP addresses. Id. at 40:32–35.
`
`The DNS proxy server handles requests for DNS look-up for secure
`
`hosts. Ex. 1001, 40:43–45. If the host is secure, then it is determined
`
`whether the user is authorized to connect with the host. Id. at 40:51–53. If
`
`the user is authorized to connect, a secure Virtual Private Network (VPN) is
`
`established between the user’s computer and the secure target site. Id. at
`
`40:66–41:2.
`
`C. Illustrative Claim
`
`Petitioner challenges claims 1–34 of the ’705 patent. Claim 1 is an
`
`independent method claim and claim 21 is an independent system claim. All
`
`remaining claims depend directly or indirectly from claim 1 or 21. Claim 1
`
`is reproduced below.
`
`1. A method of transparently creating an encrypted
`communications channel between a client device and a target
`device, each device being configured to allow secure data
`communications between the client device and the target device
`over the encrypted communications channel once the encrypted
`communications channel is created, the method comprising:
`(1) intercepting from the client device a request to look up
`an Internet Protocol (IP) address corresponding to a domain
`name associated with the target device;
`(2) determining whether the request to look up the IP
`address transmitted5 in step (1) corresponds to a device that
`
`
`5 Patent Owner asserts “transmitted” was printed in error and that the claim
`was amended to include “intercepted” instead of “transmitted.” Prelim.
`Resp. 29, n.3 (citing Ex. 1002, 638–639, 641, 655–656). Patent Owner
`represents the error will be corrected after this decision. Id. Petitioner uses
`the printed version, i.e., “transmitted.” Pet. 29, 35. The difference in
`
`
`
`5
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`
`accepts an encrypted channel connection with the client device;
`and
`(3) in response to deterring in step (2), that the request to
`look up the IP address in step (2) corresponds to a device that
`accepts an encrypted communications channel connection with
`the client device, providing provisioning information required
`to initiate the creation of the encrypted communications channel
`between the client device and the target device such that the
`encrypted communications channel supports secure data
`communications transmitted between the two devices, the client
`device being a device at which a user accesses the encrypted
`communications channel.
`
`Ex. 1001, 55:43–67.
`
`D. References relied upon
`
`Petitioner relies on the following references. Pet. 3, Attachment B.
`
`Reference
`
`Description
`
`Beser
`RFC 2401
`
`Brand
`
`
`
`US 6,496,867 B1
`S. Kent and Randall
`Atkinson, RFC 2401,
`Security Architecture
`for the Internet
`Protocol, Standards
`Track
`US 5,237,566
`
`Publication or
`Issue Date
`Dec. 17, 2002
`Nov. 1998
`
`Exhibit No.
`
`Ex. 1007
`Ex. 1008
`
`Aug. 17, 1993
`
`Ex. 1012
`
`
`language is not dispositive of any argument made by either party at this
`stage of the proceedings.
`
`
`
`6
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`
`E. Asserted grounds of unpatentability
`
`Petitioner challenges claims 1–34 of the ’705 patent as unpatentable
`
`on the following grounds. Pet. 3, 24–52.
`
`Reference(s)
`Beser and RFC 2401
`
`Beser, RFC 2401, and Brand
`
`Claims Challenged
`Basis
`§ 103(a) 1–4, 6–10, 12–26, 28–
`346
`§ 103(a) 5, 11, 277
`
`A. Claim Construction
`
`II. ANALYSIS
`
`In an inter partes review, “[a] claim in an unexpired patent shall be
`
`given its broadest reasonable construction in light of the specification of the
`
`patent in which it appears.” 37 C.F.R. § 42.100(b); see In re Cuozzo Speed
`
`Techs., LLC, 793 F.3d 1268, 1275–76 (Fed. Cir. 2015), reh’g en banc
`
`denied, 2015 WL 4100060 (Fed. Cir. July 8, 2015); see also Office Patent
`
`Trial Practice Guide, 77 Fed. Reg. 48756, 48766 (Aug. 14, 2012) (Claim
`
`Construction). Under the broadest reasonable construction standard, claim
`
`terms are given their ordinary and customary meaning, as would be
`
`understood by one of ordinary skill in the art in the context of the entire
`
`disclosure. In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir.
`
`2007). Any special definition for a claim term must be set forth in the
`
`
`6 Claim 7 is not listed as part of this ground under the “Identification of
`Claims Being Challenged.” Pet. 3. However, the Petition argues claim 7 as
`part of this ground. Id. at 45–46. Accordingly, we proceed on claim 7 as
`part of this ground.
`7 Claim 11 is not listed as part of this ground under the “Identification of
`Claims Being Challenged.” Pet. 3. However, the Petition argues claim 11
`as part of this ground. Id. at 51–52. Accordingly, we proceed on claim 11
`as part of this ground.
`
`7
`
`
`
`
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`specification with reasonable clarity, deliberateness, and precision. In re
`
`Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994). In the absence of such a
`
`special definition or other consideration, “limitations are not to be read into
`
`the claims from the specification.” In re Van Geuns, 988 F.2d 1181, 1184
`
`(Fed. Cir. 1993).
`
`Petitioner and Patent Owner each proffer proposed constructions of
`
`several claim terms. At this stage of the proceeding, neither party has
`
`identified a term for construction that is dispositive on any of the challenges.
`
`For the purposes of this Decision, and on this record, we determine that no
`
`claim term needs express interpretation. 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 “does not provide evidence to
`
`establish that RFC 2401 would have been sufficiently accessible to the
`
`public interested in the art” on November 1998, the date recited on each of
`
`its pages. Prelim. Resp. 3. According to Patent Owner, Petitioner fails to
`
`show that RFC 2401 constitutes a prior art printed publication and is
`
`therefore not properly relied upon for purposes of showing obviousness. Id.
`
`at 3–6. On this basis, Patent Owner argues that Petitioner has not satisfied
`
`its burden of showing a reasonable likelihood of prevailing with respect to
`
`any challenged claim of the ’705 patent.
`
`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
`
`
`
`8
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`public. In re Klopfenstein, 380 F.3d 1345, 1350 (Fed. Cir. 2004). We
`
`acknowledge Patent Owner’s argument regarding RFC 2401. On its face,
`
`however, RFC 2401 is a dated “Request for Comments” from the “Network
`
`Working Group,” discussing a particular standardized security protocol for
`
`the Internet. Ex. 1008. Moreover, RFC 2401 describes itself as a
`
`“document [that] specifies an Internet standards track protocol for the
`
`Internet community, and requests discussion and suggestions for
`
`improvements . . . . Distribution of this memo is unlimited.” Id. at 1; see
`
`also Ex. 1005 ¶¶ 148–155 (discussing Request for Comment (“RFC”)
`
`publications). 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,8 we are persuaded that Petitioner has made a threshold
`
`showing that RFC 2401 constitutes a prior art printed publication.
`
`Accordingly, we consider the disclosure of RFC 2401 for the purposes of
`
`this decision.
`
`C. Obviousness Over Beser and RFC 2401
`
`Petitioner alleges claims 1–4, 6–10, 12–26, and 28–34 would have
`
`been obvious over Beser and RFC 2401. Pet. 24–51. Petitioner’s evidence
`
`includes the Declaration of Roberto Tamassia (“Tamassia Declaration,” Ex.
`
`1005 ¶¶ 274–364, 383–403).
`
`
`8 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.
`
`
`
`
`9
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`
`1. Overview of Beser
`
`Beser describes a system that establishes an IP (internet protocol)
`
`tunneling association on a public network between two end devices. See Ex.
`
`1007, Abs. Figure 1 of Beser is reproduced below.
`
`
`
`Figure 1 of Beser illustrates a network system, including public network 12,
`
`network devices 24 and 26, private network 20, trusted third-party network
`
`device 30, and modified routers or gateways 14 and 16. Ex. 1007, 3:60–
`
`4:18. 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., Figs. 1, 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–
`
`
`
`10
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`47. This request includes a unique identifier for the terminating end of the
`
`tunneling association—terminating device 26. Id. at 7:64–8:3. The packets
`
`used to transfer this unique identifier across the public network “may require
`
`encryption or authentication to ensure that the unique identifier cannot be
`
`read on the public network 12.” 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 on 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:16–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 offered by the IPSec
`
`protocols, including “access control, connectionless integrity, data origin
`
`authentication, [and] . . . confidentiality (encryption).” Ex. 1008, 3–4.
`
`3. 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
`
`
`
`11
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`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. 26–27 (citing Ex. 1007, 1:54–56; Ex. 1005
`
`¶¶ 383–385, 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.” Id. at 27 (citing Ex. 1007, 1:54–56, 4:55–5:2, 11:22–25, 18:2–5;
`
`Ex. 1005 ¶¶ 282–283, 185, 383–386, 389–390, 394, 398). Moreover,
`
`Petitioner adds that a person of ordinary skill would have recognized that
`
`IPSec readily could be integrated into Beser’s systems. Id. at 28 (citing Ex.
`
`1005 ¶¶ 391–392, 398–400).
`
`Patent Owner argues that Beser and RFC 2401 would not have been
`
`combined as asserted by Petitioner. Prelim. Resp. 12–17. According to
`
`Patent Owner, Beser teaches away from using the IPSec protocol of RFC
`
`2401 for audio or 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 13 (quoting Ex. 1007, 1:64–65). Thus, Patent
`
`Owner concludes that “one of ordinary skill in the art would understand that
`
`Beser is directed to providing a method for securing communications other
`
`than encryption.” Id. at 14 (citing Ex. 2001 ¶ 56). 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
`
`
`
`12
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`objective of increasing security without increasing computational burden.”
`
`Id. at 15–16.
`
`We are not persuaded, at this point in the proceeding that Beser
`
`teaches away from adding encryption to its system. 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.
`
`Ex. 1007, 1:60–63. In addition, Beser characterizes some prior art systems
`
`as creating “security problems by preventing certain types of encryption
`
`from being used.” Id. at 2:23–24. We are, therefore, persuaded that
`
`Petitioner’s rationale that a person of ordinary skill would have found it
`
`obvious to combine the teachings of RFC 2401 with Beser is reasonable.
`
`4. Claims 1 and 21
`
`For this proceeding, Petitioner asserts that the “non-encrypted
`
`streaming audio/video example” described in Beser teaches each of the
`
`limitations of claims 1 and 21 except the required “encrypted
`
`communications channel.” Pet. 30–32, 34–41. Specifically, as per the
`
`preamble of claim 1,9 Petitioner argues that Beser’s originating end device is
`
`equivalent to the claimed client device and Beser’s terminating end device is
`
`equivalent to the claimed target device. Id. at 31.
`
`Petitioner also argues that Beser discloses step (1) of claim 1,
`
`“intercept[ing] . . . a request to look up an [] IP address corresponding to a
`
`domain name associated with the target . . . .” Id. at 32–34. Petitioner cites
`
`to Beser’s teaching that the originating end device (“client device”) sends a
`
`request to initiate a tunneling association with the terminating end device
`
`(“target device”). Id. at 32 (citing Ex. 1007, 7:64–8:1, 9:64–10:41; Ex. 1005
`
`
`9 Petitioner proceeds on the basis that the preamble is limiting and we agree.
`
`
`
`13
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`¶ 316). The request will be received “not by the terminating end device, but
`
`by a first network device, which evaluates all of the data packets it receives
`
`(i.e., the request is “intercepted” by the first network device).” Id. at 32–33
`
`(citing Ex. 1007, 8:21–47; Ex. 1005 ¶¶ 299–300, 317, 322). Petitioner also
`
`asserts that “Beser . . . shows that, even though the request contains a unique
`
`identifier associated with the terminating end device, the request is actually
`
`‘intercepted’ by each of the first network device and the trusted-third-party
`
`network device because they each receive ‘a request pertaining to a first
`
`entity at another entity.’” Pet. 33 (citing Ex. 1007, 8:21–47; Ex. 1005, ¶ 69).
`
`Step (2) of claim 1 recites “determining whether the request to look up
`
`the IP address in step (1) corresponds to a device that accepts an encrypted
`
`channel connection with the client device.” As noted above, Petitioner
`
`asserts the following:
`
`[T]he Beser streaming video or audio example does not
`necessarily encrypt all the IP traffic sent over the secure tunnel.
`This distinction would have been considered an obvious
`variation of the Beser scheme when considered with RFC 2401.
`
`Pet. 34. Specifically, Petitioner asserts Beser teaches determining
`
`whether access to a secure site has been requested. Id. (citing Ex.
`
`1001, 40:1–7; Apple Inc. v. VirnetX Inc., IPR2014-00237, slip op. at 7
`
`(PTAB May 14, 2014)(Paper 15)). Petitioner explains that Beser
`
`teaches establishing a secure tunnel between the first (client) and
`
`second (target) devices. Id. at 35 (citing Ex. 1007, 9:6–11, 9:26–30,
`
`11:9–44; Ex. 1005 ¶¶ 324, 330). Petitioner concludes that “a person
`
`of ordinary skill in the art would have considered it obvious to encrypt
`
`all IP traffic in the Beser IP tunneling scheme to include end-to-end
`
`encryption based on the teachings of RFC 2401.” Id. at 36–37 (citing
`
`
`
`14
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`Ex. 1007, 1:54–56, 11:26–58; see also Ex. 1005 ¶¶ 323–325, 330,
`
`393, 395, 398–399).
`
`Step (3) of claim 1 recites, in pertinent part, in response to step
`
`(2), “providing ‘provisioning information required to initiate . . . [an]
`
`encrypted communications channel.” Noting that Beser does not
`
`necessarily use encryption in the streaming of audio or video data,
`
`Petitioner relies on RFC 2401 to show the encryption feature of the
`
`limitation. Pet. 37. Petitioner concludes that Beser in view of RFC
`
`2401 would therefore have rendered obvious the creation of an
`
`“encrypted communications channel.” Id.
`
`Conclusion
`
`On this record we are persuaded Petitioner has established a
`
`reasonable likelihood of prevailing in its challenge that claims 1 and 21
`
`would have been obvious over Beser combined with RFC 2401.
`
`5. Claims 4 and 26
`
`Claim 4 depends from method claim 1 and recites additionally that
`
`“the encrypted communications channel is a broadband connection.” Claim
`
`26 depends from claim 21 and repeats the “broadband connection” limitation
`
`in the context of system claim 21. Petitioner asserts that data transmitted
`
`over a cable television network, as taught by Beser, is “necessarily
`
`transmitted over a broadband connection.” Pet. 44–45 (citing Ex. 1007,
`
`4:30–36, Ex. 1005 ¶¶ 80, 294, 297).
`
`Patent Owner alleges “the Petition fails to explain or show that cable
`
`television network communications would have necessitated a broadband
`
`connection at the time of the claimed inventions.” Prelim. Resp. 18. Patent
`
`Owner contends the Tamassia Declaration fails to include any discussion of
`
`
`
`15
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`claims 4 and 26 or of “why cable television communications would have
`
`necessarily required a broadband connection.” Id. Patent Owner argues that
`
`the Petition fails to provide the “underlying facts or data” required by 37
`
`C.F.R. § 41.65(a) to support the inherency position. Id. at 17–18. Patent
`
`Owner concludes that the Petition is insufficient because it fails to explain
`
`“[h]ow the construed claim is unpatentable,” and “specify where each
`
`element of the claim is found in the prior art patents or printed publications
`
`relied upon.” Id. at 19 (citing 37 C.F.R. § 42.104(b)(4)).
`
`The Tamassia Declaration at paragraph 80 discusses the terms
`
`“modulated” and “unmodulated,” which Petitioner proposed for
`
`construction. See Pet. 14. In its proposed construction of the terms,
`
`Petitioner cites to the ’705 patent’s teaching that transmission paths may
`
`comprise “logically separate paths contained within a broadband
`
`communication medium (e.g., separate channels in an FDM, TDM, CDMA,
`
`or other type of modulated or unmodulated transmission link).” Id. (citing
`
`Ex. 1001, 34:49–55). Understanding that Petitioner’s assertion is that
`
`“broadband connection” is inherent in the cable television transmission
`
`taught by Beser and that modulated signals are part of a broadband
`
`communication, we determine that this record includes sufficient specificity
`
`to meet 37 C.F.R. § 42.104(b)(4).
`
`Conclusion
`
`On this record, we are persuaded Petitioner has established a
`
`reasonable likelihood of prevailing in its challenge that claims 4 and 26
`
`would have been obvious over Beser combined with RFC 2401.
`
`
`
`16
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`
`6. Claims 14 and 31
`
`Claim 14 depends from method claim 1 and recites additionally
`
`“wherein the target device is a server.” Claim 31 depends from claim 21 and
`
`repeats the “server” limitation in the context of system claim 21. Petitioner
`
`argues Beser describes various originating and terminating end devices,
`
`including Web-TV sets and decoders, interactive vide-game players, or
`
`personal computers running multimedia applications. Pet. 46 (citing Ex.
`
`1007, 4:43–54; see also 4:14–18). Petitioner notes that Beser describes that
`
`the terminating end device can be a domain name. Id. at 46–47 (citing Ex.
`
`1007, 10:37–41, 10:55–11:5). Petitioner concludes 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 ¶ 289).
`
`Patent Owner contends neither Petitioner nor its expert provide the
`
`“underlying facts or data” required by 37 C.F.R. § 41.65(a) to support
`
`Petitioner’s contentions regarding claims 14 and 31. Prelim. Resp. 19–21.
`
`Second, Patent Owner contends the Petition does not explain how Beser
`
`inherently discloses or suggests the features of claims 14 and 31 to one of
`
`skill in the art. Id. (citing 35 U.S.C. § 314(a); 37 C.F.R. §§ 42.104(b)(4),
`
`42.408(c)).
`
`Concerning disclosure of underlying facts and data, Patent Owner
`
`contends Petitioner’s expert never specifically addresses either claim 14 or
`
`31, but does acknowledge the Tamassia Declaration states “that Web-TV
`
`and multimedia applications ‘could be used to connect to and download[]
`
`from a server.’” Prelim. Resp. 20 (citing Ex. 1005 ¶¶ 120–121, 289). Patent
`
`Owner then points to an alleged discrepancy between the Petition and the
`
`
`
`17
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`Tamassia Declaration. Id. at 20–21. The Petition alleges, as discussed
`
`above, that the terminating end device of Beser can be a domain name. Id.
`
`(citing Pet. 46–47). Conversely, the Tamassia Declaration uses the term
`
`“name server,” which is associated with the trusted-third-party network
`
`device of Beser, not the terminating end device, i.e., the “target.” Id. (citing
`
`Pet. 35, Ex. 1005 ¶ 126).
`
`We are not persuaded by Patent Owner’s arguments. First, as a
`
`factual matter, Beser describes that the terminating end device can have a
`
`domain name associated with it. See Pet. 46–47 (citing Ex. 1007, 10:37–41,
`
`10:55–11:5). Second, the Tamassia Declaration describes that the Domain
`
`Name Server (DNS) is “a distributed database that allows for address
`
`resolution via a client-server model.” Ex. 1005 ¶ 126. Moreover, Beser
`
`explicitly states, as Petitioner notes, that “the ends of the data flow may be
`
`other types of network devices and the present invention is not restricted to
`
`telephony or multimedia devices.” Pet. 46 (citing Ex. 1007, 4:52–53).
`
`Petitioner has tied Beser’s disclosure to a server via the disclosure of a
`
`domain name combined with how a Domain Name Server works in the
`
`context of the client-server model. Beser also discloses that the end device
`
`may be “other types of network devices.” Patent Owner directs us to page
`
`35 of the Petition. We have reviewed the page and are not persuaded that
`
`the discussion of “name server” in connection with claims 1 and 21 detracts
`
`from a suggestion in Beser for using a server as an end device or target.
`
`Further, as noted above, Patent Owner acknowledges the Tamassia
`
`Declaration concludes multimedia applications could be used to connect and
`
`download from a server. Prelim. Resp. 20 (citing Ex. 1005 ¶ 289). The
`
`background of Dr. Tamassia shows he is at least a person of ordinary skill in
`
`
`
`18
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`the art. His background and review of the Beser disclosure are sufficient, at
`
`this stage, to support his conclusions regarding domain names and client-
`
`server architecture. At this preliminary stage, given Dr. Tamssia’s
`
`background, his testimony that the Web-TV and multimedia applications
`
`disclosed in Beser “could” be used to connect to and download from a server
`
`and other above-discussed findings and rationale are sufficient to meet
`
`Petitioner’s burden.
`
`Conclusion
`
`On this record, we are persuaded Petitioner has established a
`
`reasonable likelihood of prevailing in its challenge that claims 14 and 31
`
`would have been obvious over Beser combined with RFC 2401.
`
`7. Claims 18–20 and 22–24
`
`Claims 18 and 22 depend from claims 1 and 21 respectively and recite
`
`that “the encrypted communications channel supports a plurality of
`
`services.” Claims 19 and 20 and claims 23 and 24 further depend directly or
`
`indirectly from claims 18 and 22, respectively.
`
`The Petition alleges the tunnel in Beser is the claimed
`
`“communications channel.” See Pet. 30–31 (claims 1 and 21). Petitioner
`
`contends that “the IP tunnel can be implemented over a variety of networks,
`
`such as the Internet, an intranet, Local Area Networks and cable television
`
`networks.” Id. at 48–49 (citing Ex. 1007, 4: 30–42; Ex. 1005 ¶¶ 294–298).
`
`Concerning the claimed “services,” Petitioner cites to Beser’s teaching that
`
`the data sent over an IP tunnel can include data for facsimile or audio
`
`applications, data for “Web-TV sets,” VoIP data, and video conference data
`
`for the “H.323 protocol,” a protocol used for multimedia communications
`
`
`
`19
`
`
`
`IPR2015-00810
`Patent 8,868,705 B2
`
`include voice. Pet. 49 (citing Ex. 1007, 4:50–52, 4:47–50, 9:67–10:2; Ex.
`
`1005 ¶¶ 286–298).
`
`Patent Owner observes the Petition alleges that “Beser’s underlying
`
`network (not the tunnel) has the capability of supporting a plurality of
`
`services.” Prelim. Resp. 21 (citing Pet. 48–49). According to Patent Owner,
`
`the Petition does not address the claim language and, as a result, fails to
`
`show a reasonable likelihood that claims 18 and 22 are unpatentable. Id. at
`
`22 (citing 35 U.S.C. § 314(a); 37 C.F.R. § 42.408(c)10). Patent Owner
`
`asserts the Petition is inadequate even if the allegation in the Petition is
`
`based on inherency. Id.
`
`Patent Owner alleges a distinction between the IP tunnel and the
`
`underlying network. We are not persuaded by this argument. As Petitioner
`
`alleges, Beser clearly states the IP tunnel may be implemented on various
`
`networks “such as the Internet, an intranet, Local Area Networks and cable
`
`television networks.” Pet. 48–49 (citing Ex. 1007, 4: 30–42; Ex. 1005
`
`¶¶ 294–298). Indeed, Patent Owner does not dispute that Beser discloses
`
`these underlying network provides services. See Pet. 49 (citing Ex. 1007,
`
`4:50–52, 4:47–50, 9:67–10:2; Ex. 1005 ¶¶ 286–298). Moreover, it is not
`
`necessary that Beser use the exact words of the claim—“encrypted
`
`communications channel.” In re Bond, 910 F.2d 831, 832 (Fed. Cir. 1990)
`
`(“These elements must be arranged as in the claim under review, but this is
`
`