throbber
Trials@uspto.gov
`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
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket