`571.272.7822
`
`
`
`
`
`Paper 10
`Filed: October 15, 2014
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_____________
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`MICROSOFT CORP.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`____________
`
`Case IPR2014-00612
`Case IPR2014-00613
`Case IPR2014-00614
`Patent 7,418,504 B21
`____________
`
`Before MICHAEL P. TIERNEY, KARL D. EASTHOM, and
`STEPHEN C. SIU, Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`
`
`DECISION
`Institution of Inter Partes Review in IPR2014-00613 and IPR2014-00614
`and Denying Institution of Inter Partes Review in IPR2014-00612
`37 C.F.R. § 42.108
`
`
`1 A copy of this Decision will be entered in each case. Hereinafter, using the
`heading style of the Scheduling Order, all papers and exhibits by the parties
`will be filed only in IPR2014-00614.
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`I.
`
`INTRODUCTION
`
`
`
`
`
`A.
`
`Background
`
`Microsoft Corporation (“Petitioner”) filed three Petitions requesting
`
`inter partes review of claims 1, 2, 6, 14–17, 19–23, 26–41, 43–47, and 50–
`
`60 of U.S. Patent No. 7,418,504 B2 (Ex. 1001, “the ’504 Patent”).
`
`VirnetX Inc. (“Patent Owner”) filed a Preliminary Response (“Prelim.
`
`Resp.”) in each of the three proceedings, as listed in the following chart.2
`
`
`
`Case No.
`
`Challenged Claims
`
`IPR2014-00612
`(“’612 IPR”)
`IPR2014-00613
`(“’613 IPR”)
`IPR2014-00614
`(“’614 IPR”)
`
`
`1, 2, 6, 14–17, 19–23, 26–
`41, 43–47, and 50–60
`1, 2, 6, 14–17, 19–23, 26–
`41, 43–47, and 50–60
`1, 2, 6, 14–17, 19–23, 26–
`41, 43–47, and 50–60
`
`
`
`Petition
`Paper No.
`
`Paper 2
`
`Preliminary
`Response
`Paper No.
`Paper 7
`
`Paper 2
`
`Paper 8
`
`Paper 1
`
`Paper 7
`
`We have jurisdiction under 35 U.S.C. § 314. Under 35 U.S.C.
`
`§ 314(a), an inter partes review may not be “instituted unless . . . the petition
`
`filed under section 311 and any response filed under section 313 shows that
`
`there is a reasonable likelihood that the petitioner would prevail with respect
`
`to at least 1 of the claims challenged in the petition.”
`
`We determine, based on the record, that Petitioner has demonstrated,
`
`under 35 U.S.C. § 314(a), that there is a reasonable likelihood it would
`
`
`2 Unless otherwise noted, citations to “Pet.,” “Prelim. Resp.,” and “Ex.”
`refer to the Petition, Preliminary Response, and Exhibits, respectively, in
`Case IPR2014-00614.
`
`2
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`prevail in establishing unpatentability with respect to all of the challenged
`
`
`
`claims, claims 1, 2, 6, 14–17, 19–23, 26–41, 43–47, and 50–60.
`
`Petitioner relies on the following references:
`
`US 6,557,037 B1 (Apr. 29, 2003) (’613 IPR, Ex. 1008, “Provino”).
`
`US 6,225,993 B1 (May 1, 2001) (Ex. 1009, “Lindblad”).
`
`P. Mockapetris, Domain Names — Concepts and Facilities,
`NETWORK WORKING GROUP, REQUEST FOR COMMENTS: 1034 1–55
`(1987) (Ex. 1010, “RFC 1034”).3
`
`E. Rescorla & A. Schiffman, The Secure HyperText Transfer
`Protocol, ENTERPRISE INTEGRATION TECHNOLOGIES 1–35 (1996) (Ex.
`1012, “RFC 2660”).4
`
`Takahiro Kiuchi & Shigekoto Kaihara, C-HTTP -- The Development
`of a Secure, Closed HTTP-based Network on the Internet,
`PROCEEDINGS OF THE SYMPOSIUM ON NETWORK AND DISTRIBUTED
`SYSTEM SECURITY, IEEE 64–75 (1996) (Ex. 1018, “Kiuchi”).
`
`Aventail Corp., Aventail Connect v3.01/v2.51 Administrator’s Guide
`and Aventail Extranet Center v3.0 Administrator’s Guide 1–194
`(1996–99) (’612 IPR, Ex. 1007, “Aventail”).
`
`Dave Kosiur, Building and Managing Virtual Private Networks (Sept. 1,
`1998) (“Kosiur”) (’613 IPR, Ex. 1024).
`
`
`
`3 Also cited as Ex. 1010 in the ’613 IPR.
`4 Also cited as Ex. 1012 in the ’613 IPR.
`3
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`
`Petitioner contends that the challenged claims are unpatentable under
`
`
`
`35 U.S.C. § 102 and/or § 103 based on the following specific grounds:
`
`Reference(s)
`
`Kiuchi
`
`Aventail5
`
`Provino
`
`Kiuchi, Aventail, or
`Provino, and RFC 1034
`Kiuchi, Aventail or
`Provino, and RFC 2660
`Kiuchi or Aventail, and
`Lindblad
`Provino and Kosiur
`
`
`Basis
`
`§ 102
`
`§ 102 or § 103
`
`§ 102
`
`§ 103
`
`§ 103
`
`§ 103
`
`§ 103
`
`Claims Challenged
`
`1, 2, 6, 14–17, 19–23,
`26–31, 33–41, 43–47,
`50–55, and 57–60
`1, 2, 6, 14–17, 19–23,
`26–41, 43–47, and 50–60
`1, 2, 6, 14–17, 19–23,
`26–41, 43–47, and 50–
`606
`20, 21, 35, 44, 45, and 59
`
`16, 27, 33, 40, 51, and 57
`
`32 and 56
`
`29–32 and 53–56
`
`Petitioner also relies on two declarations provided by Dr. Roch
`
`Guerin, Exhibit 1023 in the ’613 IPR and Exhibit 1021 in the ’614 IPR.
`
`B.
`
`The ’504 Patent
`
`The ’504 Patent describes a system and method for establishing a
`
`secure communication link between a first computer and a second computer
`
`over a computer network. Ex. 1001, 6:36–39, 48:58–60. The user obtains a
`
`
`5 In the ’612 IPR proceeding, Petitioner asserts that “Aventail” includes both
`documents listed above as part and parcel of the same document pursuant to
`an anticipation challenge, or alternatively, constitutes two documents
`pursuant to an obviousness challenge. See ’612 IPR, Pet.14, 51.
`6 Although one section heading of the Petition does not include claims 29–
`32 and 53–56 as anticipated by Provino (Pet. 14), other section headings,
`the analysis, and a table, include these claims as anticipated (Pet. 4, 45–47).
`
`4
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`secure URL (uniform resource locator) for a secure domain name by
`
`
`
`querying a secure domain name service that contains a cross-reference
`
`database of secure domain names and corresponding secure network
`
`addresses. Id. at 50:27–30, 50:65–66. When the user queries the secure
`
`domain name service for a secure computer network address, the secure
`
`domain name service determines the particular secure URL for a
`
`corresponding computer network address and returns the network address
`
`corresponding to the request. Id. at 38:61–63, 39:3–5, 51:17–47.
`
`Claim 1 of the ’504 Patent is reproduced below:
`
`1. A system for providing a domain name service for
`establishing a secure communication link, the system
`comprising:
`a domain name service system configured to be
`connected to a communication network, to store a plurality of
`domain names and corresponding network addresses, to receive
`a query for a network address, and to comprise an indication
`that the domain name service system supports establishing a
`secure communication link.
`
`
`C. Related Matters
`
`According to Petitioner, the ’504 Patent is the subject of several co-
`
`pending federal district court actions. See Pet. 1–2 (listing the actions and
`
`proceedings). The’504 Patent also has been the subject of other inter partes
`
`petitions by other parties, which have been dismissed or not instituted
`
`(failing to list all real parties-in-interest or time barred). See Pet. 2 (listing
`
`five petitions by other parties). The ’504 Patent also is the subject of two
`
`ongoing inter partes reexamination proceedings, 95/001,788 (Right of
`
`Appeal Notice (“RAN”) rejecting claims 1–60 of the ’504 Patent in a
`
`Prosecution) and 95/001,851 (RAN rejecting claims 1–10 and 12–60,
`
`5
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`
`employing Kiuchi for some obviousness rejections). See Pet. 1–2 (citing Ex.
`
`1016, Ex. 1017).
`
`The United States Court of Appeals for the Federal Circuit recently
`
`affirmed a jury’s finding that none of claims 1, 2, 5, 16, 21, and 27 of the
`
`’504 Patent are invalid in an appeal of a judgment in a district court case.
`
`See VirnetX, Inc. v. Cisco Systems, Inc., No. 2013-1489, 2014 WL 4548722
`
`(Fed. Cir. Sept. 16, 2014).
`
`
`
`D. Claim Construction
`
`The Board interprets claim terms by applying the broadest reasonable
`
`construction in the context of the specification in which the claims reside.
`
`37 C.F.R. § 42.100(b); see Office Patent Trial Practice Guide, 77 Fed. Reg.
`
`48,756, 48,766 (Aug. 14, 2012).
`
`Under the broadest reasonable 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 specification with reasonable clarity,
`
`deliberateness, and precision. In re Paulsen, 30 F.3d 1475, 1480 (Fed. Cir.
`
`1994). A particular embodiment appearing in the specification does not
`
`limit a claim if the claim language is broader than the embodiment. In re
`
`Van Geuns, 988 F.2d 1181, 1184 (Fed. Cir. 1993).
`
`In contrast to the broadest reasonable interpretation standard
`
`employed by the Board for an unexpired patent, the Federal Circuit employs
`
`a narrower claim construction standard when reviewing the construction of a
`
`claim applied by the district court. See 37 C.F.R. § 42.100 (b) (“A claim in
`
`6
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`an unexpired patent shall be given its broadest reasonable construction in
`
`
`
`light of the specification in which it appears.”); cf. In re Rambus, Inc., 694
`
`F.3d 42, 46 (Fed. Cir. 2012) (Contrasting the Board’s review of expired
`
`patents, which is “similar to that of a district court review,” with the Board’s
`
`review of unexpired patents, which involves the broadest reasonable
`
`interpretation standard).
`
`1) Secure Communication Link
`
`Claim 1 recites “a secure communication link.” Petitioner contends
`
`that a secure communication link is a “direct communication link that
`
`provides data security through encryption.” Pet. 9. Patent Owner concurs.
`
`Prelim. Resp. 17.
`
`In VirnetX, Inc. v. Cisco Systems, Inc., 2014 WL 4548722 at *4–6, 10,
`
`the Federal Circuit determined that a “secure communication link,” as used
`
`in the ’504 patent (and a related patent), means “a direct communication link
`
`that provides data security and anonymity.” Id. at *5. Central to its claim
`
`construction, the court found, based on concessions or arguments by the
`
`parties, that the ordinary meaning of the term “security,” on that record, did
`
`not apply. See id. at *4 (“There is no dispute that the word ‘secure’ does not
`
`have a plain and ordinary meaning in this context, and so must be defined by
`
`reference to the specification”).
`
`Although the parties agree that the link should be “direct,” on this
`
`record, the parties do not explain how the recited link must include an
`
`implicit requirement for a “direct” link under a broadest reasonable
`
`interpretation, using either an ordinary definition, implications from the ’504
`
`Patent Specification, or other implications. Absent further input, the record
`
`does not support, and we decline to impart, such an implied requirement for
`
`7
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`purposes of this Decision. Although the Federal Circuit interpreted the
`
`
`
`“secure communication link” to be a “direct” link, see id. at *5, the opinion
`
`does not discuss the basis for the requirement, see id. at *6. In contrast to
`
`the broadest reasonable interpretation standard employed by the Board, the
`
`Federal Circuit employs a narrower claim construction standard when
`
`reviewing the construction of a claim applied by the district court.
`
`The parties also agree that the term “secure communication link”
`
`requires encryption. Patent Owner points to examples in the ’504 Patent
`
`Specification that include encryption, and also points to extrinsic evidence.
`
`See, e.g., Prelim. Resp. 17–18 (citing Ex. 1001, 3:14–14, 39:34–45; Ex.
`
`2026; Ex. 2027; Ex. 2038; Ex. 2039).
`
`Notwithstanding the cited examples and extrinsic evidence, the ’504
`
`Patent Specification states that “[a] tremendous variety of methods have
`
`been proposed and implemented to provide security and anonymity for
`
`communications over the Internet.” Ex. 1001, 1:32–35 (emphasis added).
`
`The ’504 Patent Specification describes data security and anonymity as
`
`counterpart safeguards against eavesdropping that may occur while two
`
`computer terminals communicate over the Internet. See id. at 1:38–54.
`
`Security, in one context, may refer to protection of the data itself, to preserve
`
`the secrecy of its contents, while anonymity refers to preventing an
`
`eavesdropper from discovering the identity of a participating terminal. See
`
`id. at 1:40–54. Complicating the issue of what “secure” encompasses, the
`
`description of “security,” according to the ’504 Patent Specification,
`
`generally includes “two security issues,” address (anonymity) and data
`
`security, with completely secure communications being “immune to
`
`eavesdropping.” Id. at 1:40–50.
`
`8
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`
`According to the ’504 Patent Specification, “[d]ata security is usually
`
`
`
`tackled using some form of data encryption.” Ex. 1001, 1:55–56 (emphasis
`
`added). These descriptions involving what “usually” occurs and the
`
`reference to a “tremendous variety of methods” imply that “security” may
`
`include, but does not require, encryption. In VirnetX, Inc. v. Cisco Systems,
`
`Inc., 2014 WL 4548722 at *4–6, 10, the Federal Circuit, citing the same and
`
`similar passages in the ’504 Patent and a related VirnetX patent
`
`specification, determined that “security” does not require encryption.
`
`Further supporting the implication that security does not require
`
`encryption, the ’504 Patent Specification provides a specific example that
`
`employs “unencrypted message packets,” while using “different levels of
`
`authentication,” and, under some circumstances, “a keyed hopping
`
`sequence.” See Ex. 1001, col. 54, ll. 40–67. Another example shows that
`
`“unencrypted message packets” can be modified by inserting data packets
`
`into them to form a virtual private connection that “can be conveniently
`
`authenticated so that, for example, a denial of service attack can be rapidly
`
`rejected, thereby providing different levels of service.” Id. at 54:13–17.
`
`The ’504 Patent also describes “various embodiments” which form a
`
`“secure communication” by “‘hopping’ different addresses using one or
`
`more algorithms and one or more moving windows that track a range of
`
`valid addresses to validate received packets.” Id. at 21:46–50. Using this
`
`hopping technique on “[p]ackets transmitted according to one or more of the
`
`inventive principles will be generally referred to as ‘secure’ packets or
`
`‘secure communications.’” Id. at 21:50–55.
`
`The ’504 Patent also explains that “[a]ccording to the invention, a
`
`virtual private connection does not provide the same level of security . . . as
`
`9
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`a virtual private network.” Id. at 54:13–14. In other words, given the
`
`
`
`different examples and general descriptions that encompass a wide variety of
`
`techniques, the ’504 Patent Specification describes different levels of
`
`security by using different methods to obtain different security levels,
`
`rendering the term “secure” relative.
`
`Therefore, similar to the determination in the Federal Circuit, on this
`
`record, neither Petitioner nor Patent Owner demonstrate persuasively that
`
`the ’504 Patent Specification requires “encryption” for a “secure
`
`communication link.” Notwithstanding the Federal Circuit’s determination
`
`on that record that a “secure communication link” requires “anonymity,” the
`
`parties do not urge anonymity as an implicit feature of the claim term in this
`
`proceeding. No apparent reason exists on this record to require anonymity
`
`as an implied limitation.
`
`As noted, in contrast to the broadest reasonable interpretation standard
`
`employed by the Board for an unexpired patent, the Federal Circuit employs
`
`a narrower claim construction standard when reviewing the construction of a
`
`claim applied by the district court. Moreover, in a related inter partes
`
`proceeding between the same parties and involving a continuation patent of
`
`the ’504 Patent, Patent Owner argued that the “patent specification supports
`
`the view” that anonymity is not required: “[a] link that prevents others from
`
`understanding the communications sent over it may still be considered
`
`‘secure’ even if the communicating parties do not enjoy any anonymity.”
`
`Apple Inc. v. VirnetX Inc., Case IPR2014-00237, slip op. at 22 (PTAB Mar.
`
`6, 2014) (Paper 12 (citing U.S. Patent No. 8,504,697 B2, 39:40–58)).
`
`Two technical dictionaries on this record support Patent Owner’s
`
`argument that the term “secure,” in the context of communications, carries
`
`10
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`an ordinary meaning that does not require anonymity. For example,
`
`
`
`“security” is “[t]he existence and enforcement of techniques which restrict
`
`access to data, and the conditions under which data may be obtained.” Ex.
`
`3002 (MCGRAW-HILL DICTIONARY OF SCIENTIFIC AND TECHNICAL TERMS
`
`1780 (5th ed. 1994)). Similarly, a “security service” carries the following
`
`meaning:
`
`(1) A service, provided by a layer of communicating open
`systems, that ensures adequate security of the systems or of data
`transfers. . . . (2) The capability of the system to ensure the
`security of system resources or data transfers. Access controls,
`authentication, data confidentiality, data integrity, and
`nonrepudiation are traditional data communications security
`services.
`
`Ex. 3003 (IEEE 100, THE AUTHORITATIVE DICTIONARY OF IEEE STANDARDS
`
`TERMS 1016 (7th ed. 2000) (emphasis omitted), available at
`
`http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4116807).7
`
`Based on the foregoing discussion, for this Decision, the term “secure
`
`communication link” means “a transmission path that restricts access to data,
`
`addresses, or other information on the path, generally using obfuscation
`
`methods to hide information on the path, including, but not limited to, one or
`
`more of authentication, encryption, or address hopping.”
`
`
`
`
`
`
`
`
`7 The Board cited this evidence in the related inter partes proceeding
`involving a common specification with the ’504 Patent. Apple Inc. v.
`VirnetX Inc., Case IPR2014-00237, slip op. at 9–10 (PTAB May 14, 2014)
`(Paper 15, Institution Decision).
`
`11
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`
`
`
`
`2) Indication
`
`Claim 1 recites “an indication that the domain name service system
`
`supports establishing a secure communication link.” Petitioner contends that
`
`“indication” means “a visible or non-visible message or signal that the DNS
`
`system supports establishing a secure communication link, including the
`
`establishment of the secure communication link itself.” Pet. 8. Patent
`
`Owner argues that “indication,” according to claim 1, is separate and distinct
`
`from the establishment of the secure communication link. See Prelim. Resp.
`
`16 (citing Ex. 1001, 55:49–50, 54–56––i.e., claim 1 limitations, including
`
`the preamble).
`
`Neither Petitioner nor Patent Owner point to an explicit definition of
`
`the term “indication” in the Specification. The term “indication” ordinarily
`
`means “the action of indicating” or “something (as a signal, sign,
`
`suggestion) that serves to indicate.” Ex. 3001 (WEBSTER’S THIRD NEW
`
`INTERNATIONAL DICTIONARY 1150 (1971)). The term “indicate” ordinarily
`
`means “to point out or point to or toward with more or less exactness” or “to
`
`show the probable presence or existence or nature or course of.” Id. On this
`
`record, the Specification is not inconsistent with the ordinary meaning or
`
`Petitioner’s construction. See, e.g., Ex. 1001, 40:49–41:15 (sending a “host
`
`unknown” signal if a user is not authorized, but simply establishing a link if
`
`a user is authorized).
`
`Therefore, for purposes of this Decision, the term “indication”
`
`broadly, but reasonably, means “something that shows the probable presence
`
`or existence or nature of.” In accordance with this construction, in context
`
`of claim 1, an indication that a secure communication link is in operation
`
`12
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`constitutes an indication that the system supports establishing a secure
`
`
`
`communication link.
`
`3) Other Claim Terms
`
`The parties do not disagree materially about other claim terms
`
`involved in this proceeding. It is not necessary to define explicitly other
`
`claim terms for purposes of this Decision.
`
`
`
`
`
`II. ANALYSIS
`
`A.
`
`Cited References
`
`
`
`1) Overview of Kiuchi
`
`Kiuchi discloses a closed Hyper Text Transfer Protocol (HTTP)-based
`
`network (C-HTTP) for a closed group of institutions, in which each member
`
`is protected by its own firewall. Ex. 1018, 64, cols. 1–2. Communication is
`
`made possible with a client-side proxy (for one institution), a server-side
`
`proxy (for another institution), and a C-HTTP name server that provides
`
`both client-side and server-side proxies with each peer’s public key and
`
`Nonce values for both a request and a response. Id. at 64–65.
`
`The client-side proxy asks the C-HTTP name server whether it can
`
`communicate with the host specified in a given URL. If the connection is
`
`permitted, the C-HTTP name server sends the IP address and public key of
`
`the server-side proxy and both request and response Nonce values, which are
`
`encrypted and certified using asymmetric key encryption and digital
`
`signature technology. Id. at 65, col. 2.
`
`The client-side proxy then sends an encrypted request (including “the
`
`client-side proxy’s IP address, hostname, request Nonce value, and
`
`symmetric data exchange key for request[ing] encryption”) to the server-side
`
`13
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`proxy, which then asks the C-HTTP name server if the query from the
`
`
`
`client-side proxy is legitimate. Id. at 65, col. 2. If the request is confirmed
`
`to be legitimate and access is permitted, the C-HTTP name server sends the
`
`IP address and public key of the client-side proxy and both request and
`
`response Nonce values to the server-side proxy. After receiving the client-
`
`side proxy’s IP address, hostname and public key, the server-side proxy
`
`generates and sends a connection ID to the client-side proxy. After the
`
`client-side proxy accepts the connection ID from the server-side proxy, the
`
`connection is established. Id. at 66, col. 2.
`
`2) Overview of Provino
`
`Provino generally describes a secure communication system between
`
`a virtual private network and an external device. The system encrypts “at
`
`least the data portion of message packets,” and the requester’s address. See
`
`’613 IPR, Ex. 1008, 5:48, 5:43–52, 6:10–28, Abstract.
`
`Figure 1 of Provino follows:
`
`Figure 1 represents Provino’s system, which includes external devices
`
`12(1)–12(m), Internet 14, and VPN 15.
`
`
`
`14
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`
`According to Provino, to locate devices on a network, users typically
`
`
`
`prefer human-readable domain names, called secondary addresses, instead of
`
`integer-based addresses, all of which the Internet provides. These human-
`
`readable names (secondary addresses) must be translated, by a nameserver,
`
`into a digital integer or network address carried by a packet to indicate the
`
`destination address. Public nameservers do not have the network address for
`
`devices behind the firewall of a private network, such as VPN 15. Id. at
`
`10:45–55. Nameserver 32, behind firewall 30, in VPN 15, stores the
`
`associated network address and secondary address (name) of devices in the
`
`VPN (behind the firewall). Provino’s system provides a mechanism for
`
`device 12(m) outside the firewall to use the human-readable secondary
`
`address, and obtain the integer-based network address from VPN
`
`nameserver 32, to allow external devices 12(m) to communicate with
`
`devices behind the firewall via a secure tunnel. Id. at 1:36–65, 3:66–4:22,
`
`9:32–38, 10:45–67.
`
`
`
`Provino’s device 12(m) includes secure message packet processor 26
`
`to facilitate a “secure tunnel . . . in secret by, for example, encrypting the
`
`data portion.” See id. at 5:44–52. VPN 15 has similar devices 12(m’),
`
`including workstations, personal computers, etc. Id. at 6:10–28. Devices
`
`12(m) communicate with VPN 15 and devices 13 in VPN 15. Id. at 5:66–
`
`6:15. During the process of obtaining the internet addresses for the human-
`
`readable addresses, firewall 30 and device 12(m) cooperate “to establish a
`
`secure tunnel therebetween, in addition to possibly providing the device
`
`12(m) with . . . encryption and decryption algorithms and keys which are to
`
`be used in connection with the message packets transferred over the secure
`
`tunnel.” Id. at 10:56–67.
`
`15
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`
`
`
`In summary, Provino provides a secure tunnel through Internet 14 in a
`
`first phase to firewall 30, and in a second phase, provides the resolution
`
`between the human-readable names and encrypted Internet addresses for
`
`devices behind firewall 30 of VPN 15. Id. at 12:4–45. “Thereafter, . . .
`
`device 12(m) can use the integer Internet address to generate message
`
`packets for transfer over the Internet . . . .” Id. at 13:51–53; accord id. at
`
`15:27–30.
`
`
`
`Ultimately, the system provides for “easing communications . . . over
`
`a secure tunnel” between public devices on Internet 14 and private devices
`
`in VPN 15. Id. at 15:59–65. More specifically, in terms of Figure 1,
`
`Provino describes a system that facilitates encrypted communications
`
`between client device 12(m) connected to ISP (internet service provider) 11
`
`and server 31(s) located within VPN 15. See id. at 10:13–44; Ex. 1011
`
`¶¶ 28–31.
`
`3) Overview of RFC 2660
`
`RFC 2660 discloses a client and server authenticating each other and
`
`exchanging sensitive information confidentially using secure communication
`
`mechanisms between an HTTP client-server pair. Ex. 1012, 5:8–10, 13–14.
`
`4) Overview of Lindblad
`
`Lindblad discloses the use of documents with HTTP of the World
`
`Wide Web in which such documents “incorporate text, graphical images,
`
`sound, and motion video.” Ex. 1009, 1:64 – 2:1. The documents may be
`
`read and displayed by a multimedia document viewer. Id. at 4:38–43.
`
`5) Overview of RFC 1034
`
` RFC 1034 discloses a name server that answers standard queries in
`
`recursive mode or non-recursive mode. Ex. 1010, 21. In non-recursive
`
`16
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`mode, the server is unable to provide an answer to the request and refers to
`
`
`
`“some other server ‘closer’ to the answer.” In recursive mode, the server
`
`“returns either an error or the answer, but never referrals.” Id.
`
`6) Overview of Kosiur
`
`Kosiur teaches “a wide variety of applications [that] can run on
`
`Networks,” including virtual private networks. ’613 IPR, Ex. 1024, 244.
`
`For example, Kosiur teaches that a VPN can support “newer applications,
`
`such as interactive multimedia and videoconferencing,” id. at 254, “file
`
`transfers, Web browsing, and e-mail,” “IP telephony,” and other
`
`“transactional traffic,” id. at 249.
`
`B.
`
`Preliminary Argument
`
`Although the Petition does not exceed the page limit, Patent Owner
`
`maintains that the Petition is defective because it “uses a font that the Board
`
`has deemed noncompliant for being too narrow.” Prelim. Resp. 1. We
`
`decline to exercise our discretion to deny the Petition for lack of a correct
`
`font.
`
`C.
`
`Anticipation by Kiuchi
`
`Petitioner asserts that claims 1, 2, 6, 14–17, 19–23, 26–31, 33–41, 43–
`
`47, 50–55, and 57–60 are anticipated under 35 U.S.C. § 102 by Kiuchi. Pet.
`
`14–51. In support of this asserted ground of unpatentability, Petitioner
`
`provides explanations as to how each claim limitation recited in claims 1, 2,
`
`6, 14–17, 19–23, 26–31, 33–41, 43–47, 50–55, and 57–60 is disclosed by
`
`Kiuchi. Id. Upon consideration of Petitioner’s analysis and supporting
`
`evidence, and taking into account Patent Owner’s Preliminary Response, on
`
`this record, Petitioner has demonstrated a reasonable likelihood that it would
`
`17
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`prevail with respect to anticipation of claims 1, 2, 6, 14–17, 19–23, 26–31,
`
`
`
`33–41, 43–47, 50–55, and 57–60 over Kiuchi.
`
`In VirnetX, Inc. v. Cisco Systems, Inc., 2014 WL 4548722 at *11, the
`
`Federal Circuit held that “substantial evidence” supported a jury verdict that
`
`Kiuchi does not disclose a “direct communication.” The opinion, however,
`
`does not address why the claims require a “direct” communication. As
`
`determined above in the Claim Construction section, this record does not
`
`support, under a broadest reasonable interpretation, importing a “direct”
`
`connection or communication limitation from the ’504 Patent Specification,
`
`file history, or otherwise, as an implicit limitation of the recited “secure
`
`communication link” in claim 1.
`
`Claim 1 recites a system for providing a domain name service for
`
`establishing a secure communication link that is connected to a
`
`communication network and stores a plurality of domain names and
`
`corresponding network addresses. Claims 36 and 60 recite similar features.
`
`Petitioner argues that Kiuchi discloses client- and server-side proxies,
`
`working in conjunction with a C-HTTP name server, that the C-HTTP name
`
`server of Kiuchi “automatically and transparently perform[s] . . . name
`
`resolution and establishment of secure connections,” that the system is
`
`“configured and arranged to be (and is) connected to the Internet (a
`
`communication network),” and that the “C-HTTP name server stores . . .
`
`information . . . and uses it to resolve hostnames into IP addresses in
`
`response to queries.” Pet. 24–25 (citing Ex. 1018, 64–65; §§ 2.2, 2.3(1)–
`
`(2)).
`
`Petitioner has made a sufficient showing that Kiuchi discloses a
`
`secure communication link connected to a communication network (e.g., an
`
`18
`
`
`
`
`IPR2014-00612, IPR2014-00613, and IPR2014-00614
`Patent 7,418,504 B2
`
`
`“HTTP (Hypertext Transfer Protocol)-based network (C-HTTP) which can
`
`
`
`be built on the Internet,” Ex. 1018, 64) and stores a plurality of domain
`
`names and corresponding network addresses (e.g., the C-HTTP contains and
`
`“sends the IP address and public key of the server-side proxy and both
`
`request and response Nonce values,” Ex. 1018, 65). Kiuchi states that “a
`
`C-HTTP includes its own secure name service, which contains a certification
`
`mechanism, [so that] it is impossible to know the IP address of a server-side
`
`proxy.” Id., 68, col. 1. Kiuchi also provides data security. Id., 69, col. 1.
`
`Kiuchi discloses various forms of security: virtual directories, a certification
`
`process, authentication, a firewall, and encryption of the client-side’s IP
`
`address, hostname, and other portions of a request. See id., 65, cols. 1, 2; 66
`
`col. 2. Therefore, on this record, Kiuchi discloses a secure connection.
`
`Claim 1 also recites a domain name service system that receives a
`
`query for a network address and provides an indication that the domain
`
`name service system supports establishing a secure communication link.
`
`Claims 36 and 60 recite similar features. Petitioner argues that Kiuchi
`
`discloses a “client-side proxy [that] receives a request from a user agent for a
`
`resource associated with a hostname specified in a URL,” that “the C-HTTP
`
`name server receives a request for a network address,” and “the C-HTTP
`
`name server returns a network address.” Pet. 26 (citing Ex. 1018, 65–66).
`
`Kiuchi discloses receiving a query for a network address, because, for
`
`example, Kiuchi discloses that a “client-side proxy asks the C-HTTP name
`
`server whether it ca