Paper No. 1
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________________
`
`
`
`APPLE INC.
`Petitioner,
`
`v.
`
`VIRNETX, INC. AND SCIENCE APPLICATION INTERNATIONAL
`CORPORATION,
`Patent Owner.
`
`Patent No. 8,868,705
`Issued: October 21, 2014
`Filed: September 13, 2012
`Inventors: Victor Larson, et al.
`Title: AGILE NETWORK PROTOCOL FOR SECURE COMMUNICATIONS
`USING SECURE DOMAIN NAMES
`
`____________________
`
`Inter Partes Review No. IPR2015-00810
`__________________________________________________________________
`
`Petition for Inter Partes Review of
`U.S. Patent No. 8,868,705
`
`
`
`
`
`
`

`
`
`
`I.
`
`Table of Contents
`
`Introduction .................................................................................................... 1
`A. Certification the ’705 Patent May Be Contested by Petitioner ....... 1
`B.
`Fee for Inter Partes Review (§ 42.15(a)) ........................................... 1
`C. Mandatory Notices (37 CFR § 42.8(b)) ............................................. 1
`1.
`Real Party in Interest (§ 42.8(b)(1)) ............................................ 1
`2.
`Other Proceedings (§ 42.8(b)(2)) ................................................ 2
`3.
`Lead and Backup Lead Counsel (§ 42.8(b)(3)) .......................... 2
`4.
`Service Information (§ 42.8(b)(4)) ............................................. 3
`5.
`Proof of Service (§§ 42.6(e) and 42.105(a)) ............................... 3
`
`II.
`
`Identification of Claims Being Challenged (§ 42.104(b)) ........................... 3
`
`B.
`C.
`D.
`E.
`
`III. Relevant Information Concerning the Contested Patent .......................... 4
`A. Overview of the ’705 Patent ............................................................... 4
`1.
`The ’705 Patent Specification ..................................................... 4
`2.
`Representative Claims ................................................................ 6
`Patent Owner’s Contentions About Related Patents ....................... 6
`Effective Filing Date ............................................................................ 7
`The Person of Ordinary Skill in the Art ........................................... 9
`Claim Construction ............................................................................. 9
`1.
`“intercept[ing] . . . a request” .................................................... 10
`2.
`“domain name” ......................................................................... 11
`3.
`“secure domain name” .............................................................. 11
`4.
`“provisioning information” ....................................................... 12
`5.
`“modulated transmission link” /
`“unmodulated transmission link” .............................................. 13
`“phone” ..................................................................................... 15
`
`6.
`
`IV. Analysis of the Patentability of the ’705 Patent ........................................ 15
`A. Overview of Beser (Ex. 1007) ........................................................... 15
`ii
`
`

`
`2.
`
`
`
`
`
`a)
`Request Containing a Unique Identifier ......................... 17
`Negotiation of Private IP Addresses ............................... 20
`b)
`B. Overview of RFC 2401 (Ex. 1008) ................................................... 22
`C. Overview of Brand (Ex. 1012) .......................................................... 24
`D.
`Beser (Ex. 1007) In View of RFC 2401 (Ex. 1008) Would Have
`Rendered Obvious Claims 1-4, 6-10, 12-26 and 28-34 ................... 24
`1.
`A Person of Ordinary Skill Would Have Found It Obvious to
`Encrypt IP Traffic in the Beser Scheme Based on the Teachings
`in Beser and RFC 2401 ............................................................. 26
`Independent Claims 1 and 21 Would Have Been Obvious ...... 30
`a)
`Claim Preambles ............................................................. 30
`b)
`“intercept[ing] . . . a request to look up an [] IP address
`corresponding to a domain name associated with the
`target . . .” ....................................................................... 32
`“determin[e/ing] whether the request . . . corresponds to a
`device that accepts an encrypted channel connection” .. 34
`In response to step (2) “provid[e/ing] provisioning
`information required to initiate . . . [an] encrypted
`communications channel” ............................................... 37
`“the client device being a device at which a user accesses
`the encrypted communications channel” ........................ 40
`Claims 8, 15, 30 and 32 Would Have Been Obvious ............... 41
`3.
`Claims 2 and 9 Would Have Been Obvious ............................. 42
`4.
`Claims 3, 10 and 25 Would Have Been Obvious ..................... 43
`5.
`Claims 4 and 26 Would Have Been Obvious ........................... 44
`6.
`Claims 6, 12 and 28 Would Have Been Obvious ..................... 45
`7.
`Claims 7, 13 and 29 Would Have Been Obvious ..................... 45
`8.
`Claims 14 and 31 Would Have Been Obvious ......................... 46
`9.
`10. Claims 16 and 33 Would Have Been Obvious ......................... 47
`11. Claims 17 and 34 Would Have Been Obvious ......................... 48
`12. Claims 18 and 22 Would Have Been Obvious ......................... 48
`13. Claims 19 and 23 Would Have Been Obvious ......................... 49
`iii
`
`c)
`
`d)
`
`e)
`
`

`
`
`
`14. Claims 20 and 24 Would Have Been Obvious ......................... 50
`Beser In View of RFC 2401 Further In View of Brand (Ex. 1012)
`Would Have Rendered Obvious Claims 5, 11 and 27 .................... 51
`No Secondary Considerations Exist ................................................ 52
`
`E.
`
`F.
`
`V. Conclusion .................................................................................................... 53
`
`
`
`iv
`
`

`
`Petition in IPR2015-00810
`
`I.
`
`Introduction
`A. Certification the ’705 Patent May Be Contested by Petitioner
`Petitioner certifies that U.S. Patent No. 8,868,705 (Ex. 1001) (the ’705
`
`patent) is available for inter partes review. Petitioner also certifies it is not barred
`
`or estopped from requesting inter partes review of the claims of the ’705 patent.
`
`Neither Petitioner, nor any party in privity with Petitioner, has filed a civil action
`
`challenging the validity of any claim of the ’705 patent. The ’705 patent has not
`
`been the subject of a prior inter partes review by Petitioner or a privy of Petitioner.
`
`Petitioner also certifies this petition for inter partes review is timely filed as
`
`it has never been asserted against Petitioner in litigation. Thus, because there is no
`
`patent owner’s action, this petition complies with 35 U.S.C. § 315(b). Petitioner
`
`also notes that the timing provisions of 35 U.S.C. § 311(c) and 37 C.F.R.
`
`§ 42.102(a) do not apply to the ’705 patent, as it pre-dates the first-to-file system.
`
`See Pub. L. 112-274 § 1(n), 126 Stat. 2456 (Jan. 14, 2013).
`
`Fee for Inter Partes Review (§ 42.15(a))
`
`B.
`The Director is authorized to charge the fee specified by 37 CFR § 42.15(a)
`
`to Deposit Account No. 50-1597.
`
`C. Mandatory Notices (37 CFR § 42.8(b))
`1.
`Real Party in Interest (§ 42.8(b)(1))
`The real party in interest of this petition pursuant to § 42.8(b)(1) is Apple
`
`Inc. (“Apple”) located at One Infinite Loop, Cupertino, CA 95014.
`
`1
`
`

`
`Petition in IPR2015-00810
`
`2. Other Proceedings (§ 42.8(b)(2))
`IPR2015-00811 filed concurrently also involves the ’705 patent. Each
`
`petition advances unique grounds and are based on different primary references.
`
`IPR2015-00811 challenges the claims of the ’705 patent on obviousness grounds
`
`based on “Aventail Connect v3.01/v2.51 Administrator’s Guide” (Ex. 1009) in
`
`combination with “Request for Comments: 2401; Security Architecture for the
`
`Internet Protocol” (Ex. 1008), and further in combination with “RFC 2543; SIP:
`
`Session Initiation Protocol” (Ex. 1013) and/or U.S. Patent No. 5,237,566 to Brand
`
`(Ex. 1012). These references show that the Aventail VPN system for creating
`
`virtual private networks using encrypted and authenticated connections in
`
`combination with the IPsec protocol, further in combination with the SIP protocol
`
`and/or the baseband network teachings disclosed in Brand, would have rendered
`
`obvious the DNS-based systems and methods for establishing an encrypted
`
`communications channel according to the ’705 claims.
`
`The present petition and IPR2015-00811 present unique correlations of the
`
`challenged ’705 claims to the prior art, and each warrants independent institution
`
`of trial. Petitioner respectfully requests the Board institute each petition, as each
`
`presents distinct and non-redundant grounds.
`
`Lead and Backup Lead Counsel (§ 42.8(b)(3))
`
`3.
`Lead Counsel is: Jeffrey P. Kushan (Reg. No. 43,401), jkushan@sidley.com,
`
`
`
`2
`
`

`
`Petition in IPR2015-00810
`
`(202) 736-8914. Back-Up Lead Counsel are: Scott Border (pro hac to be
`
`requested), sborder@sidley.com, (202) 736-8818; and Thomas A. Broughan III
`
`(Reg. No. 66,001), tbroughan@sidley.com, (202) 736-8314.
`
`Service Information (§ 42.8(b)(4))
`
`4.
`Service on Petitioner may be made by e-mail (iprnotices@sidley.com), mail
`
`or hand delivery to: Sidley Austin LLP, 1501 K Street, N.W., Washington, D.C.
`
`20005. The fax number for lead and backup lead counsel is (202) 736-8711.
`
`5.
`Proof of Service (§§ 42.6(e) and 42.105(a))
`Proof of service of this petition is provided in Attachment A.
`
`II.
`
`Identification of Claims Being Challenged (§ 42.104(b))
`Claims 1-34 of the ’705 patent are unpatentable for being obvious under 35
`
`U.S.C. § 103. Specifically:
`
`(i) Claims 1-4, 6, 8-26 and 28-34 are obvious under 35 U.S.C. § 103
`
`based on U.S. Patent No. 6,496,867 to Beser (“Beser”) (Ex. 1007) in view of “RFC
`
`2401, Security Architecture for the Internet Protocol,” (“RFC 2401”) (Ex. 1008)
`
`and the knowledge of a person of ordinary skill in the art;
`
`(ii) Claims 5, 7 and 27 are obvious under 35 U.S.C. § 103 based on Beser
`
`in view of RFC 2401 and further in view of U.S. Patent No. 5,237,566 to Brand
`
`(“Brand”) (Ex. 1012) and the knowledge of a person of ordinary skill in the art.
`
`A list of evidence relied upon in support of this petition is set forth in
`
`Attachment B.
`
`
`3
`
`

`
`Petition in IPR2015-00810
`
`III. Relevant Information Concerning the Contested Patent
`A. Overview of the ’705 Patent
`1.
`The ’705 Patent Specification
`The ’705 patent is a member of a family of patents issued to Larson et al.,
`
`including, inter alia, U.S. Patent Nos. 6,502,135 (“ ’135 patent”), 7,188,180
`
`(“ ’180 patent”), 7,418,504 (“ ’504 patent”), 7,490,151 (“ ’151 patent”), 7,921,211
`
`(“ ’211 patent”), 7,987,274 (“ ’274 patent”), 8,051,181 (“ ’181 patent”), 8,504,697
`
`(“ ’697 patent”), and 8,850,009 (“ ’009 patent”).1
`
`The ’705 patent disclosure, like other members of this patent family, is
`
`largely focused on techniques for securely communicating over the Internet based
`
`on a protocol called the “Tunneled Agile Routing Protocol” or “TARP.” Ex. 1001
`
`at 3:16-19. According to the ’705 specification, TARP allows for secure and
`
`anonymous communications by using tunneling, an IP address hopping scheme
`
`where the IP addresses of the end devices and routers participating in the system
`
`can change over time, and a variety of other security techniques. Ex. 1001 at 1:35-
`
`38, 3:16-6:9. Two short sections of the ’705 specification – spanning primarily
`
`columns 39 to 42 and 49 to 53 – are directed to a different concept, namely,
`
`techniques for establishing secure communications in response to DNS requests
`
`
`
`1
`
`
`
`IPR2015-00812 and -00813 filed concurrently involve the ’009 patent.
`
`4
`
`

`
`Petition in IPR2015-00810
`
`specifying a secure destination. See Ex. 1001 at 38:62-41:53, 48:63-55:36. This
`
`material was added in a continuation-in-part application filed in February 2000. In
`
`proceedings involving related patents, Patent Owner has asserted that these short
`
`passages provide written description support for claim terms involving domain
`
`names, DNS requests, requests to look up network addresses, and DNS servers.
`
`These portions of the ’705 specification describe a “conventional DNS
`
`server” that purportedly is modified to include additional functionality that allows
`
`it to support creating virtual private networks. See Ex. 1001 at 39:58-40:19.
`
`According to the ’705 specification, the “modified DNS server” (id. at 39:62-64)
`
`receives a request to look up a network address associated with a domain name,
`
`determines whether a secure site has been requested (for example, by checking an
`
`internal table of sites), and then performs additional steps to support establishing a
`
`“virtual private network” with the secure site. See Ex. 1001 at 38:65-67, 39:41-51,
`
`40:1-19, 40:59-41:9, 51:29-35. This process can include conventional devices
`
`such as personal computers running web browsers, proxy servers, intermediate
`
`routers, and web servers. Ex. 1001 at 39:58-67, 49:10-20, 52:20-26.
`
`The ’705 specification describes several optional features of this system,
`
`such as using “IP hopblocks” to create a VPN or incorporating user authentication.
`
`Ex. 1001 at 39:47-51, 39:56-57, 41:2-9, 51:43-56. It also describes several
`
`optional configurations of the “modified DNS server,” including a standalone DNS
`
`
`
`5
`
`

`
`Petition in IPR2015-00810
`
`server and a system incorporating a DNS server, a DNS proxy server, and a
`
`gatekeeper. Ex. 1001 at 40:30-42.
`
`Representative Claims
`
`2.
`Independent claims 1 and 21 of the ’705 patent define a method and a
`
`system, respectively, but recite the same operative steps. See Ex. 1001 at 55:43-
`
`67, 56:58-57:15. Claim 1 is representative, specifying a method of creating an
`
`encrypted communications channel between a client device and a target device by:
`
`(1) intercepting a request from the client device to look up an Internet Protocol (IP)
`
`address corresponding to a domain name associated with the target device; (2)
`
`determining whether the request corresponds to a device that accepts an encrypted
`
`channel connection with the client device; and (3) in response to the determination
`
`in step (2), providing provisioning information required to initiate the creation of
`
`the encrypted communications channel between the client device and the target
`
`device, the client device being a device at which a user accesses the encrypted
`
`communications channel.
`
`Patent Owner’s Assertion of Related Patents
`
`B.
`Patent Owner has asserted varying sets of claims of its patents in this family
`
`against Petitioner and other entities in numerous lawsuits. In August of 2010,
`
`Patent Owner sued Petitioner and five other entities (the “2010 Litigation”)
`
`asserting claims from the ’135, ’151, ’504, and ’211 patents. In November 2011,
`
`
`
`6
`
`

`
`Petition in IPR2015-00810
`
`Patent Owner filed a lawsuit accusing Petitioner of infringing claims of the ’181
`
`patent. In December 2012, Patent Owner served a new complaint on Petitioner
`
`asserting infringement of numerous claims of the ’135, ’151, ’504, and ’211
`
`patents (the “2012 Litigation”). In August 2013, Patent Owner served an amended
`
`complaint adding the ’697 patent to the 2012 Litigation. Patent Owner also
`
`asserted patents from this family against Microsoft and others in separate lawsuits
`
`filed in February 2007, March 2010, and April 2013, and against numerous other
`
`defendants in actions filed in 2010 and 2011.
`
`C. Effective Filing Date
`The ’705 patent issued from U.S. Appl. No. 13/615,557 (“the ’557
`
`application”). The ’557 application claims the benefit as a continuation of the
`
`following applications: 13/049,552 (issued as U.S. Patent No. 8,572,247);
`
`11/840,560 (issued as the ’211 patent); 10/714,849 (issued as the ’504 patent); and
`
`09/558,210, filed April 26, 2000, and now abandoned. It also is designated a
`
`continuation-in-part of 09/504,783, filed on February 15, 2000 (“the ’783
`
`application”), which is a continuation-in-part of 09/429,643, filed on October 29,
`
`1999. The ’210, ’783 and ’643 applications also claim priority to 60/106,261, filed
`
`October 30, 1998 and 60/137,704, filed June 7, 1998.
`
`Claims 1 and 21 of the ’705 patent are independent claims. Claims 2-20
`
`depend directly or indirectly from claim 1, and claims 22-34 depend directly or
`
`
`
`7
`
`

`
`Petition in IPR2015-00810
`
`indirectly from claim 21. Claims 2-20 and 22-34 cannot enjoy an effective filing
`
`date earlier than that of claims 1 and 21, respectively, from which they depend.
`
`Claims 1 and 21 of the ’705 patent rely on information found only in the
`
`’783 application. For example, claim 1 of the ’705 patent specifies “intercepting
`
`… a request to look up an Internet Protocol (IP) address corresponding to a
`
`domain name ….” (emphasis added). Claim 21 specifies “[a] system … including
`
`… a server configuration arranged to: intercept … a request to look up an Internet
`
`Protocol (IP) address corresponding to a domain name … .” (emphasis added).
`
`No application filed prior to the ’783 application mentions the term “domain
`
`name,” much less provide a written description of systems or processes
`
`corresponding to the ’705 patent claims. In proceedings involving the related ’135,
`
`’504, ’151, ’211, ’274 and ’697 patents, Patent Owner has not disputed that claims
`
`reciting a “domain name” are not entitled to an effective filing date prior to
`
`February 15, 2000. See, e.g., Patent Owner Preliminary Oppositions in IPR2013-
`
`00348, -00349, -00354, -00375 to -00378, -00393, -00394, -00397, and -00398, as
`
`well as IPR2014-00237, -00238, -00403, -00404, and -00610; see also Inter Partes
`
`Reexamination Nos. 95/001,682, 95/001,679, 95/001,697, 95/001,714, 95/001,788,
`
`and 95/001,789. Accordingly, the effective filing date of the ’705 patent claims is
`
`no earlier than February 15, 2000.
`
`
`
`
`
`8
`
`

`
`Petition in IPR2015-00810
`
`D. The Person of Ordinary Skill in the Art
`A person of ordinary skill in the art in the field of the ’705 patent would
`
`have been someone with a good working knowledge of networking protocols,
`
`including those employing security techniques, as well as computer systems that
`
`support these protocols and techniques. The person also would be very familiar
`
`with Internet standards related to communications and security, and with a variety
`
`of client-server systems and technologies. The person would have gained this
`
`knowledge either through education and training, several years of practical
`
`working experience, or through a combination of these. Ex. 1005 ¶ 110.
`
`E. Claim Construction
`In this proceeding, claims must be given their broadest reasonable
`
`construction in light of the specification. 37 CFR § 42.100(b). The ’705 patent
`
`shares a common disclosure and uses several of the same terms as the ’697, ’274,
`
`’180, ’151, ’504, and ’211 patents with respect to which Patent Owner has
`
`advanced constructions. If Patent Owner contends terms in the claims should be
`
`read as having a special meaning, those contentions should be disregarded unless
`
`Patent Owner also amends the claims compliant with 35 U.S.C. § 112 to make
`
`them expressly correspond to those contentions. See 77 Fed. Reg. 48764 at II.B.6
`
`(August 14, 2012); cf. In re Youman, 679 F.3d 1335, 1343 (Fed. Cir. 2012). In the
`
`constructions below, Petitioner identifies representative subject matter within the
`
`
`
`9
`
`

`
`Petition in IPR2015-00810
`
`scope of the claims, read with their broadest reasonable interpretation. Petitioner
`
`expressly reserves its right to advance different constructions in any district court
`
`litigation, which employs a different claim construction standard.
`
`1.
`“intercept[ing] . . . a request”
`Each independent claim recites the term “intercept[ing] . . . a request.” In a
`
`related proceeding involving the ’697 patent, the Board interpreted the term
`
`“intercepting” as including “receiving a request pertaining to a first entity at
`
`another entity.” IPR2014-00237, Paper 15 at 13 (May 14, 2014). The Board
`
`further explained that “intercepting” a request involves “receiving and acting on” a
`
`request, the request being “intended for” receipt at a destination other than the
`
`destination at which the request is intercepted. Id. at 12. The Board’s construction
`
`is consistent with the ’705 patent specification. Ex. 1005 at ¶ 67.
`
`The ’705 patent does not expressly define the phrase “intercepting . . . a
`
`request,” but uses the term “intercepting” as meaning receiving a request at a
`
`device other than the device specified in the request. Ex. 1005 at ¶ 68. For
`
`example, the specification explains that a DNS proxy 2610 “intercepts” all DNS
`
`lookup functions to examine whether access to a secure site has been requested.
`
`Ex. 1001 at 40:1-7, Figs. 26 & 27. The specification also shows the requests are
`
`routed to the DNS proxy instead of a DNS server 2609, which ordinarily would
`
`receive and resolve the domain name in the request. Id. at 39:1-3. Because the
`
`
`
`10
`
`

`
`Petition in IPR2015-00810
`
`DNS proxy and DNS server as described as separate entities, the ’705 patent uses
`
`the term “intercept” as meaning receipt of a message by a proxy server instead of
`
`the intended destination. Accordingly, the broadest reasonable interpretation of the
`
`term “intercepting . . . a request” includes “receiving a request pertaining to a first
`
`entity at another entity.” Ex. 1005 at ¶ 69.
`
`2.
`“domain name”
`Each independent claim recites a “domain name.” The ’705 patent does not
`
`define “domain name.” A “domain name” would be understood by a person of
`
`ordinary skill to be a hierarchical sequence of words in decreasing order of
`
`specificity that corresponds to a numerical IP address. Ex. 1005 at ¶ 70. A more
`
`general description of “domain name” has been advanced by Patent Owner in other
`
`proceedings; namely, “a name corresponding to an IP address.” See, e.g., Ex. 1042
`
`at 14-15. Both definitions are reasonable; thus the broadest reasonable
`
`interpretation of “domain name” is “a name corresponding to an IP address.”
`
`Ex. 1005 at ¶ 70.
`
`3.
`“secure domain name”
`Dependent claims 3 and 10 recite the term “secure domain name,” and
`
`specify a “secure domain name” is a type of “domain name.” In a related
`
`proceeding involving the ’180 patent, the Board found “a ‘secure domain name’ is
`
`a name that corresponds to a secure computer network address.” IPR2015-00481,
`
`
`
`11
`
`

`
`Petition in IPR2015-00810
`
`Paper 11 at 8 (Sept. 3, 2014). This is consistent with the ’705 patent disclosure.
`
`For example, the specification describes a “secure domain name” as a
`
`domain name that corresponds to the secure network address of a secure server
`
`3320. See Ex. 1001 at 51:6-42. The ’705 patent also describes evaluating domain
`
`names in DNS requests to determine whether access to a secure site has been
`
`requested. Id. at 40:1-7. The disclosure also explains that “[e]ach secure computer
`
`network address is based on a non-standard top-level domain name, such as .scom,
`
`.sorg, .snet, .sedu, .smil and .sint.” Id. at 7:39-42. Accordingly, the broadest
`
`reasonable interpretation of the term “secure domain name” would be “a name
`
`that corresponds to a secure computer network address.” Ex. 1005 at ¶ 73.
`
`4.
`“provisioning information”
`Each independent claim recites the term “provisioning information.” The
`
`’705 patent does not define “provisioning information.” The only discussion in
`
`specification concerning “provisioning” states that “VPN gatekeeper 3314
`
`provisions computer 3301 and secure web server computer 3320, or a secure edge
`
`router for server computer 3320, thereby creating the VPN.” Ex. 1001 at 51:32-35
`
`(emphasis added). The ’705 specification also explains that, after a DNS proxy
`
`determines that access a secure site has been requested, it transmits a message to a
`
`gatekeeper requesting creation of a “virtual private network.” Id. at 40:7-10,
`
`40:66-41:2. The gatekeeper returns a resolved IP address and IP address
`
`
`
`12
`
`

`
`Petition in IPR2015-00810
`
`“hopblocks” to be used by the client computer and the target site to communicate
`
`securely. Id. at 40:9-19; see also Ex. 1005 at ¶ 74.
`
`In IPR2014-00481 involving the ’180 patent, whose claims recite
`
`provisioning information for a “virtual private network” rather than “encrypted
`
`communications channel,” the Board interpreted “provisioning information” as
`
`“information that is provided to enable or to aid in establishing communications to
`
`occur in the VPN.” Paper 11 at 11 (Sept. 3, 2014). The ’705 patent disclosure
`
`only describes use of DNS systems to establish VPN connections between devices,
`
`and it does not describe creating encrypted channels that are isolated from a VPN.
`
`See Ex. 1001 at 38:65-67, 50:53-56, 51:31-35, Fig. 37. Examples of “provisioning
`
`information” in the ’705 patent includes IP address hopblocks or other data that
`
`enables or aids in establishing communications in a VPN where the VPN uses
`
`encryption. Ex. 1001 at 40:7-19; Ex. 1005 at ¶ 75. Therefore, the broadest
`
`reasonable interpretation of the term “provisioning information” in the context of
`
`the ’705 claims is “information that enables communication in a virtual private
`
`network, where the virtual private network uses encryption.” Ex. 1005 at ¶ 76.
`
`5.
`
`“modulated transmission link” /
`“unmodulated transmission link”
`Dependent claims 5, 11 and 27 recite the term “unmodulated transmission
`
`link.” Dependent claims 6, 12 and 28 recite the term “modulated transmission
`
`link.” Neither term is defined in the ’705 patent. In IPR2014-00237 involving the
`
`
`
`13
`
`

`
`Petition in IPR2015-00810
`
`related ’697 patent, the Board interpreted “modulation” to include “the process of
`
`encoding data for transmission over a medium by varying a carrier signal.” Paper
`
`15 at 14 (May 14, 2014). This is consistent with the ’705 patent and the
`
`understanding of a person of ordinary skill in the art. Ex. 1005 at ¶¶ 78-79. For
`
`example, the specification explains 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).” Ex. 1001 at 34:49-55.
`
`A person of skill would understand “unmodulated” and “modulated” to refer
`
`to whether data is encoded for transmission over a physical medium by varying or
`
`“modulating” a carrier signal. Ex. 1005 at ¶ 80. Any data transmitted via a
`
`modem (i.e., a “modulator-demodulator” device) is modulated. Id. Similarly, any
`
`data transmitted via a cellular network is modulated. Id. Conversely, any data
`
`transmitted via a baseband network is unmodulated. Id. Therefore, the broadest
`
`reasonable interpretation of “modulated transmission link” is “a communication
`
`medium for transmitting data that is encoded by varying a carrier signal.”
`
`Ex. 1005 at ¶ 81. The broadest reasonable interpretation of “unmodulated
`
`transmission link” is “a communication medium for transmitting data that is not
`
`encoded by varying a carrier signal.” Id.
`
`
`
`
`
`14
`
`

`
`Petition in IPR2015-00810
`
`6.
`“phone”
`Dependent claims 8, 15, 30, and 32 recite the term “phone.” The ’705
`
`patent does not define or use the term “phone” but states that “telephony” is an
`
`example of an “application program[]” that may be executed on a “computer
`
`node[].” Ex. 1001 at 21:21-28. “Phone” in the context of the ’705 patent
`
`disclosure therefore encompasses a device or component that can provide
`
`telephony functionality. This is consistent with the ordinary meaning of “phone.”
`
`Ex. 1005 at ¶ 82. The broadest reasonable interpretation of “phone” is therefore “a
`
`device or component that can provide telephony functionality.” Ex. 1005 at ¶ 83.
`
`IV. Analysis of the Patentability of the ’705 Patent
`The ’705 patent has two independent claims (claims 1 and 21), each of
`
`which specifies the same operative steps. See § III.A.2. Claim 1 is representative
`
`and, as explained above, defines a process for establishing an encrypted
`
`communications channel between a client device and a target device in response to
`
`a request to look up an IP address.
`
`A. Overview of Beser (Ex. 1007)
`Beser (Ex. 1007) was filed on August 27, 1999, and is prior art to the ’705
`
`claims under 35 U.S.C. § 102(e). Ex. 1007 at 1. The operation and features of the
`
`Beser system are explained in greater detail in Ex. 1005 at ¶¶ 274-345.
`
`
`
`15
`
`

`
`Petition in IPR2015-00810
`
`Beser describes methods and systems for establishing an IP tunneling
`
`association between originating (24) and terminating (26) end devices, with the aid
`
`of a first network device (14), a second network device (16), and a trusted-third-
`
`party network device (30). Ex. 1007 at 2:46-67. Fig. 1 provides an illustrative
`
`embodiment for the invention disclosed in Beser:
`
`
`
`Id. at Fig. 1.
`
`Beser explains that the originating and terminating end devices can be
`
`telephony devices (including portable “VoIP devices” and “personal computers
`
`running facsimile or audio applications”) or multimedia devices (such as “Web-TV
`
`sets [], interactive video game players, [and] personal computers running
`
`
`
`16
`
`

`
`Petition in IPR2015-00810
`
`multimedia applications”). Id. 1007 at 4:43-52. The first and second network
`
`devices may be edge routers, “gateway” computers, cable modems, or other
`
`network devices. Id. at 4:7-42. Beser further explains that the trusted-third-party
`
`network device can be “a back-end service, a domain name server, or the
`
`owner/manager of database or directory services.” Id. at 4:9-11. As Beser
`
`explains, its system is intended to be integrated into conventional network devices
`
`and configurations. Id. at 4:55-5:2; Ex. 1005 at ¶¶ 282-83, 285.
`
`a)
`
`Request Containing a Unique Identifier
`
`To establish an IP tunneling association in the Beser scheme, the originating
`
`end device sends a request containing a “unique identifier” specifying a destination
`
`(i.e., a terminating end device). Ex. 1007 at 7:63-8:3. This is illustrated in Fig. 6:
`
`
`
`17
`
`
`
`

`
`Petition in IPR2015-00810
`
`Id. at Fig. 6.
`
`Beser teaches that many types of identifiers can be used for the unique
`
`identifier, but that in one preferred embodiment, the unique identifier is a domain
`
`name. Id. at 10:37-41; Ex. 1005 at ¶ 276, 318-19. As an example of the Beser
`
`system, a VoIP application running on a portable telephony device could initiate an
`
`IP tunnel by sending out a request that included a domain name associated with the
`
`terminating end device. Ex. 1007 at 4:50-52, 10:55-66; Ex. 1005 at ¶ 320. As
`
`another example, the request could be sent by a personal computer running a
`
`multimedia application or a web browser, and it could include a domain name of
`
`the web server containing multimedia content as the unique identifier. Ex. 1007 at
`
`4:47-54, Fig. 1; Ex. 1005 at ¶ 320. Other examples of unique identifiers include
`
`email addresses and E.164 compliant telephone numbers. Ex. 1007 at 10:37-11:5;
`
`Ex. 1005 at ¶ 276.
`
`Next, the first network device receives the request, evaluates it to determine
`
`whether it is a tunneling request, and if so, sends it to the trusted-third-party
`
`network device. Ex. 1007 at 8:21-52; Ex. 1005 at ¶¶ 299-300, 317, 322.
`
`Otherwise, the first network device processes the request normally, such as by
`
`sending it to a conventional DNS server. Ex. 1007 at 4:7-42; Ex. 1005 at ¶ 300,
`
`317, 322. Beser shows that one way the first network device can determine
`
`whether to send the request to the trusted-third-party network device is by
`
`
`
`18
`
`

`
`Petition in IPR2015-00810
`
`checking the datagram for a distinctive sequence of bits indicating that it is part of
`
`a tunneling association. Ex. 1007 at 8:34-47; Ex. 1005 at ¶¶ 299-300. If the
`
`datagram does not contain this distinctive sequence indicating the request should
`
`be re-directed to the trusted third party network device, it will be handled by
`
`ordinary procedures. Ex. 1005 at ¶ 309.
`
`However, if the request contains the distinctive sequence, it is re-directed to
`
`the trusted-third-party network device, which receives and evaluates the request
`
`and determines whether it corresponds to a terminating end device that can
`
`communicate