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

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