Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`Paper No. 1
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`APPLE INC.
`Petitioner,
`
`v.
`
`VIRNETX, INC. AND SCIENCE APPLICATION INTERNATIONAL
`CORPORATION,
`Patent Owner
`
`Patent No. 7,921,211
`Issued: Apr. 5, 2011
`Filed: Aug. 17, 2007
`Inventor: Victor Larson, et al.
`AGILE NETWORK PROTOCOL FOR SECURE
`COMMUNICATIONS USING SECURE DOMAIN NAMES
`____________________
`Inter Partes Review No. IPR2015-00185
`
`
`
`
`
`
`
`Title:
`
`PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 7,921,211
`UNDER 35 U.S.C. §§ 311-319 AND 37 C.F.R. § 42.1-.80 & 42.100-.123
`________________________
`
`
`
`
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`TABLE OF CONTENTS
`
`I. MANDATORY NOTICES UNDER 37 C.F.R § 42.8(a)(1) ....................... 1
`A.
`Real Party-In-Interest Under 37 C.F.R. § 42.8(b)(1) ............................ 1
`B.
`Related Matters Under 37 C.F.R. § 42.8(b)(2) ..................................... 2
`C.
`Lead And Back-Up Counsel Under 37 C.F.R. § 42.8(b)(3) ................. 3
`D.
`Service Information ............................................................................... 3
`II.
`PAYMENT OF FEES – 37 C.F.R. § 42.103 ................................................ 3
`III. REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104 ....................... 3
`A. Grounds for Standing Under 37 C.F.R. § 42.104(a) ............................. 3
`B.
`Challenge Under 37 C.F.R. § 42.104(b) and Relief Requested ............ 4
`C.
`Claim Construction under 37 C.F.R. §§ 42.104(b)(3) .......................... 5
`1. Domain Name (Claims 1, 2, 6, 14-17, 19-23, 26-41, 43-47,
`and 50-60) ....................................................................................... 5
`2. Domain Name Service System (Claims 1, 2, 5, 6, 14-17, 19-
`23, 26-41, 43-47, and 50-60) ........................................................... 6
`3. Indicate/Indicating (Claims 1, 2, 6, 14-17, 19-23, 26-41, 43-
`47, and 50-60) ................................................................................. 7
`4. Secure Communication Link (Claims 1, 16-17, 20-23, 26-
`27, 31-32, 35-36, 47, 51, and 60) .................................................... 8
`5. Transparently (Claims 27 and 51) ................................................... 9
`6. Between [A] and [B] (Claims 16, 27, 33, 40, 51, and 57) .............. 9
`IV. SUMMARY OF THE ‘211 PATENT ........................................................ 10
`V. DETAILED DESCRIPTION WHY THE CHALLENGED
`CLAIMS ARE UNPATENTABLE ............................................................ 10
`A.
`23, 26-31, 33-41, 43-47, 50-55, and 57-60 ......................................... 10
`1. Kiuchi Anticipates Claim 1 ........................................................... 20
`2. Kiuchi Anticipates Claim 36 ......................................................... 25
`3. Kiuchi Anticipates Claim 60 ......................................................... 27
`
`[GROUND 1] – Kiuchi Anticipates Claims 1, 2, 6, 14-17, 19-
`
`i
`
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`[GROUND 2] – Kiuchi In View of RFC 1034 Renders Obvious
`
`B.
`C.
`D.
`E.
`
`4. Kiuchi Anticipates Claims 2 and 37 ............................................. 28
`5. Kiuchi Anticipates Claim 6 ........................................................... 29
`6. Kiuchi Anticipates Claims 14 and 38 ........................................... 29
`7. Kiuchi Anticipates Claims 15 and 39 ........................................... 30
`8. Kiuchi Anticipates Claims 16 and 40 ........................................... 31
`9. Kiuchi Anticipates Claims 17 and 41 ........................................... 36
`10. Kiuchi Anticipates Claims 19 and 43 ........................................... 39
`11. Kiuchi Anticipates Claims 20 and 44 ........................................... 39
`12. Kiuchi Anticipates Claims 21 and 45 ........................................... 40
`13. Kiuchi Anticipates Claims 22 and 46 ........................................... 41
`14. Kiuchi Anticipates Claims 23 and 47 ........................................... 42
`15. Kiuchi Anticipates Claims 26 and 50 ........................................... 42
`16. Kiuchi Anticipates Claims 27, 33, 51, and 57 .............................. 43
`17. Kiuchi Anticipates Claims 28 and 52 ........................................... 44
`18. Kiuchi Anticipates Claims 29 and 53 ........................................... 44
`19. Kiuchi Anticipates Claims 30 and 54 ........................................... 45
`20. Kiuchi Anticipates Claims 31 and 55 ........................................... 47
`21. Kiuchi Anticipates Claims 34 and 58 ........................................... 48
`22. Kiuchi Anticipates Claims 35 and 59 ........................................... 49
`Claims 20, 21, 35, 44, 45, and 59 ........................................................ 51
`Claims 32 and 56 ................................................................................. 52
`Claims 16, 27, 33, 40, 51, and 57 ........................................................ 54
`[GROUND 5] – Kiuchi Anticipates Claim 5 ...................................... 58
`
`[GROUND 3] – Kiuchi In View of Lindblad Renders Obvious
`
`[GROUND 4] – Kiuchi In View of RFC 2660 Renders Obvious
`
`
`Attachment A. Proof of Service of the Petition
`
`Attachment B. List of Evidence and Exhibits Relied Upon in Petition
`
`ii
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`
`
`iii
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`Apple Inc. (“Petitioner” or “Apple”) petitions for Inter Partes Review
`
`(“IPR”) under 35 U.S.C. §§ 311–319 and 37 C.F.R. § 42 of claims 1, 2, 5, 6, 14-
`
`17, 19-23, 26-41, 43-47, and 50-60 (“the Challenged Claims”) of U.S. Patent No.
`
`7,921,211 (“the ‘211 patent”). By its accompanying Motion for Joinder, Petitioner
`
`seeks to join this petition to IPR2014-00615, a proceeding instituted on the same
`
`patent and the same prior art. This petition presents one additional ground relative
`
`to IPR2014-00615 establishing that dependent claim 5 is unpatentable. Claim 5 is
`
`highly similar to claims 23 and 47 involved in the -00615 proceeding – each claim
`
`specifies “authenticat[ing] the query” with claim 5 further specifying “using a
`
`cryptographic technique.” Claim 5 is unpatentable over the same prior art that the
`
`Board has found to show the Challenged Claims unpatentable. See IPR2014-
`
`00615, Paper No. 9 at 18-21. It is submitted that consideration of this additional
`
`ground on a single claim will not impose a burden on the Panel given the common
`
`prior art and similarity to issues already being considered in the -00615
`
`proceeding, as explained in the Motion for Joinder.
`
`I. MANDATORY NOTICES UNDER 37 C.F.R § 42.8(a)(1)
`A. Real Party-In-Interest Under 37 C.F.R. § 42.8(b)(1)
`The real party of interest of this petition pursuant to § 42.8(b)(1) is Apple
`
`Inc. (“Apple”) located at One Infinite Loop, Cupertino, CA 95014.
`
`
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`B. Related Matters Under 37 C.F.R. § 42.8(b)(2)
`The ‘211 patent is the subject of a number of civil actions including: (i) Civ.
`
`Act. No. 6:13-cv-00211-LED (E.D. Tex.), filed February 26, 2013; (ii) Civ. Act.
`
`No. 6:12-cv-00855-LED (E.D. Tex.), filed November 6, 2012; (iii) Civ. Act. No.
`
`6:10-cv-00417-LED (E.D. Tex.), filed August 11, 2010; (iv) Civ. Act. No. 6:11-cv-
`
`00018-LED (E.D. Tex), (iv) Civ. Act. No. 6:13-cv-00351-LED (E.D. Tex), filed
`
`April 22, 2013 (“the 2013 VirnetX litigation”); (v) Civ. Act. No. 6:13-mc-00037
`
`(E.D. Tex); and (vi) Civ. Act. No. 9:13-mc-80769 (E.D. Fld).
`
`The ‘211 patent is also the subject of two inter partes reexamination nos.
`
`95/001,789 and 95/001,856. On May 23, 2014, the Office issued a Right of Appeal
`
`Notice in the ‘789 proceeding, maintaining rejections of all 60 claims in the ‘211
`
`patent. Similarly, on May 30, 2014, the Office issued a an Action Closing
`
`Prosecution in the ‘856 proceeding maintaining rejections of claims 1-10 and 12-
`
`60 as obvious based on Kiuchi (Ex. 1018).
`
`The ‘211 patent is the subject of two inter partes reviews filed by Microsoft
`
`Corporation (IPR2014-00615 & -00618), both instituted on October 15, 2014. The
`
`‘211 patent was also the subject of petitions for inter partes review filed by New
`
`Bay Capital, LLC (IPR2013-00378, dismissed); Apple, Inc. (IPR2013-00397 & -
`
`00398, not instituted); RPX Corporation (IPR2014-00174 & -00175, not
`
`instituted); and Microsoft Corporation (IPR2014-00616, not instituted).
`
`2
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`Concurrently with this petition, Petitioner is filing one other petition for
`
`inter partes review of the ’211 patent, identified as IPR2015-00186.
`
`C. Lead And Back-Up Counsel Under 37 C.F.R. § 42.8(b)(3)
`
`Lead Counsel
`Jeffrey P. Kushan (Reg. No. 43,401)
`jkushan@sidley.com
`(202) 736-8914
`D.
`Service Information
`Service on Petitioner may be made by e-mail, or by mail or hand delivery to:
`
`Backup Lead Counsel
`Joseph A. Micallef (Reg. No. 39,772)
`jmicallef@sidley.com
`(202) 736-8492
`
`Sidley Austin LLP, 1501 K Street, N.W., Washington, D.C. 20005. The fax
`
`number for lead and backup counsel is (202) 736-8711.
`
`II.
`
`PAYMENT OF FEES – 37 C.F.R. § 42.103
`
`The Director is authorized to charge the fee specified by 37 CFR § 42.15(a)
`
`to Deposit Account No. 50-1597.
`
`III. REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104
`A. Grounds for Standing Under 37 C.F.R. § 42.104(a)
`Petitioner certifies that the ’211 patent is available for inter partes review by
`
`Petitioner. The Petitioner is not barred or estopped from requesting an inter
`
`partes review challenging the patent claims on the grounds identified in the
`
`petition. The ’211 patent was asserted against Petitioner in proceedings alleging
`
`infringement more than one year ago, but because this petition is accompanied by a
`
`motion for joinder to IPR2014-00615, the one-year period in 35 U.S.C. § 315(b)
`
`does not apply to this petition pursuant to 35 U.S.C. § 315(c). E.g., Dell Inc. v.
`
`3
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`Network-1 Security Solutions, Inc., IPR2013-00385, Paper 17 at 4-5; Microsoft
`
`Corp. v. Proxyconn, Inc., IPR2013-00109, Paper 15 at 4-5. This petition is
`
`presented within one month of institution of trial in IPR2014-00615 (i.e., on
`
`October 15, 2014), as required by § 122(b). For the reasons detailed in the
`
`accompanying Motion for Joinder, proceedings based on the petitions should be
`
`joined to IPR2014-00615.
`
`B. Challenge Under 37 C.F.R. § 42.104(b) and Relief Requested
`Petitioner requests an IPR of the Challenged Claims on the grounds set forth
`
`below, and requests that each of the Challenged Claims be found unpatentable. The
`
`Board has already instituted trial on Grounds 1-4 below in IPR2014-00615.
`
`Petitioner presents the same Grounds in this Petition, plus one new Ground for one
`
`additional claim (Claim 5) based on the same prior art reference used to institute
`
`trial in Ground 1. A detailed explanation why Claim 5 is unpatentable is provided
`
`below in § V.E.
`
`The ‘211 patent issued from a string of applications allegedly dating back to
`
`an original application filed on October 30, 1998. However, the effective filing
`
`date for the embodiments recited by Challenged Claims of the ‘211 patent is no
`
`earlier than February 15, 2000.
`
`Kiuchi qualifies as prior art under 35 U.S.C. § 102(b). Specifically, Kiuchi
`
`(Ex. 1018) is a printed publication that was presented at the 1996 Symposium on
`
`4
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`Network and Distributed Systems Security (SNDSS) on February 22 & 23, 1996,
`
`and published by IEEE in the Proceedings of SNDSS 1996. Ex. 1018.
`
`RFC 1034 qualifies as prior art under 35 U.S.C. § 102(b). Specifically, RFC
`
`1034 (Ex. 1010) was published in November 1987 by the Internet Engineering
`
`Task Force (IETF). Ex. 1010.
`
`Lindblad qualifies as prior art under 35 U.S.C. § 102(e). Specifically,
`
`Lindblad (Ex. 1009) is a patent that was filed on April 22, 1996 and issued May 1,
`
`2001. Ex. 1009. Therefore, Lindblad is a patent that issued on an application that
`
`was filed before any of the applications to which the ‘211 patent claims priority.
`
`RFC 2660 qualifies as prior art under 35 U.S.C. § 102(b). Specifically, draft
`
`01 of RFC 2660 (Ex. 1012) was published in February 1996 by the Internet
`
`Engineering Task Force (IETF). RFC 2660 was publically distributed no later than
`
`February 1996. Ex. 1012.
`
`C. Claim Construction under 37 C.F.R. §§ 42.104(b)(3)
`Petitioner proposes use of the same constructions adopted by the Board in
`
`IPR2014-00615 and -00618.
`
`1.
`
` Domain Name (Claims 1, 2, 5, 6, 14-17, 19-23, 26-41, 43-47,
`and 50-60)
`
`The Patent Owner has asserted to the PTAB that a “domain name” means “a
`
`name corresponding to a network address.” See Ex. 1019 at 31-32; Ex. 1020 at 28-
`
`29. In view of the Patent Owner’s assertion, it is reasonable, for purposes of this
`
`5
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`proceeding in which the broadest reasonable construction standard applies, to
`
`consider the term “domain name” as encompassing “a name corresponding to a
`
`network address.”
`
`2.
`
`Domain Name Service System (Claims 1, 2, 5, 6, 14-17, 19-
`23, 26-41, 43-47, and 50-60)
`
`The Patent Owner has asserted to the PTAB and in litigation that no
`
`construction of “domain name service system” was necessary. Ex. 1013 at 24-25;
`
`Ex. 1018 at 37-39; Ex. 1020 at 34-36. According to the Patent Owner, the claims
`
`themselves define the characteristics of the domain name service system. Id. In
`
`view of the Patent Owner’s assertions, it is reasonable, for purposes of this
`
`proceeding in which the broadest reasonable construction standard applies, to
`
`consider the term “domain name service system” as encompassing any system with
`
`the characteristics described by the claims.
`
`In general, under a broadest reasonable construction standard, a “system”
`
`can include one or more discrete computers or devices. Ex. 1021 at 15. This is
`
`consistent with the ‘211 patent’s specification at col. 40, lines 35-48. This section
`
`describes a domain name service system that includes a modified DNS server 2602
`
`and a gatekeeper server 2603, which is shown as being separate from the modified
`
`DNS server. Ex. 1001 at col. 40, lines 35-48 and fig. 26. Moreover, this sections
`
`states that “although element 2602 [(the modified DNS server)] is shown as
`
`combining the functions of two servers [(the DNS proxy 2610 and DNS server
`
`6
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`2609)], the two servers can be made to operate independently.” Ex. 1001 at col. 40,
`
`lines 46-48.
`
`Also, the Examiner in the ’789 and ‘856 reexamination proceedings
`
`concluded that the broadest reasonable construction of a system encompasses a
`
`single or multiple devices. Ex. 1016 at 17, Ex. 1017 at 23 (a “DNS system is
`
`reasonably interpreted as comprising a single device or multiple devices.”).
`
`Accordingly, it is reasonable, for purposes of this proceeding in which the
`
`broadest reasonable construction standard applies, to consider the term “domain
`
`name service system” as encompassing any system with the characteristics
`
`specified by the claims, where the system may include one or more devices or
`
`computers.
`
`3.
`
`Indicate/Indicating (Claims 1, 2, 5, 6, 14-17, 19-23, 26-41,
`43-47, and 50-60)
`
`The Patent Owner has asserted to the PTAB that no construction of
`
`“indicate” or “indicating” is necessary. Ex. 1019 at 44-46; Ex. 1020 at 41-43.
`
`Similarly, in litigation for the ‘211 patent, the Patent Owner asserted no
`
`construction of “indicate” or “indicating” was necessary, and the Court also
`
`declined to construe the term. Ex. 1013 at 31; Ex. 1015 at 28. In light of this, we
`
`consider the previous reexamination proceedings. In the ’789 and ‘856
`
`reexamination proceedings, the Examiner found that, under the broadest reasonable
`
`construction, the term encompassed:
`
`7
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`the ability of the user to communicate using a secure link after boot-
`up.” If the user attempts to establish a secure communication link using a
`DNS system after booting and is able to do so, then the user has been
`provided a broadly recited and discernible “indication” that the DNS in
`some manner supports establishing a communication link.
`Ex. 1017 at 24 (emphasis original).
`
`The Examiner also found that, under the broadest reasonable construction,
`
`the term encompassed:
`
`“a visible message or signal to a user that the DNS system supports
`establishing a secure communication link”
`Ex. 1016 at 20; Ex. 1017 at 25 (emphasis original).
`
`The Examiner further concluded that, under the broadest reasonable
`
`construction, “[n]either the specification nor the claim language provides a basis
`
`for limiting 'indicating' to a visual indicator.” Ex. 1017 at 26.
`
`The broadest reasonable construction of “indicate” or “indicating” should
`
`thus encompass 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.
`
`4.
`
`Secure Communication Link (Claims 1, 16-17, 20-23, 26-27,
`31-32, 35-36, 47, 51, and 60)
`
`The Patent Owner has asserted to the PTAB that “secure communication
`
`link” should mean a “direct communication link that provides data security through
`
`encryption.” Ex. 1018 at 40-43; Ex. 1020 at 37-40. In view of the Patent Owner’s
`
`8
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`assertions, it is reasonable, for purposes of this proceeding in which the broadest
`
`reasonable construction standard applies, to consider the term “secure
`
`communication link” as encompassing a “direct communication link that provides
`
`data security through encryption.”
`
`Transparently (Claims 27 and 51)
`
`5.
`The Patent Owner has asserted to the PTAB that “transparently” means that
`
`“the user need not be involved in creating the [secure communication link]/[secure
`
`link].” Ex. 1019 at 46-47; Ex. 1020 at 43-44. In view of the Patent Owner’s
`
`assertions, it is reasonable, for purposes of this proceeding in which the broadest
`
`reasonable construction standard applies, to consider the term “transparently” as
`
`encompassing “the user need not be involved in creating the [secure
`
`communication link]/[secure link].”
`
`Between [A] and [B] (Claims 16, 27, 33, 40, 51, and 57)
`
`6.
`In prior litigation on the ‘211 patent, the Patent Owner argued against a
`
`defendant’s construction that “between” should mean “extend from one endpoint
`
`to the other,” and instead stated that “between” should only apply to the “public
`
`communication paths.” Ex. 1014 at 11. Under the Patent Owner’s contentions, a
`
`secure communication link is “between” two endpoints where encryption is used
`
`on the public communication paths between the two endpoints, regardless of
`
`whether the encryption extends completely from the first endpoint to the second
`
`9
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`endpoint. Id. In view of the Patent Owner’s assertions, it is reasonable, for
`
`purposes of this proceeding in which the broadest reasonable construction standard
`
`applies, to consider a secure communication link “between [A] and [B]” to
`
`encompass a secure communication link on the public communication paths
`
`between the two endpoints, regardless of whether that secure communication link
`
`fully extends from the first endpoint to the second endpoint.
`
`IV. SUMMARY OF THE ‘211 PATENT
`Petitioner refers the Board to the Decisions to Institute Trial in IPR2014-
`
`00615 and -00618 at pages 4 to 5 and the Petitions filed in each such proceeding
`
`for a general description of the ‘211 patent. Paper Nos. 2 at 10-13.
`
`V. DETAILED DESCRIPTION WHY THE CHALLENGED CLAIMS
`ARE UNPATENTABLE
`
`This request shows how the primary references above, alone or in
`
`combination with other references, disclose the limitations of the Challenged
`
`Claims, thereby demonstrating the Challenged Claims of the '211 patent are
`
`unpatentable. As detailed below, this request shows a reasonable likelihood that the
`
`Requester will prevail with respect to the Challenged Claims of the ‘211 patent.
`
`A.
`[GROUND 1] – Kiuchi Anticipates Claims 1, 2, 6, 14-17, 19-23,
`26-31, 33-41, 43-47, 50-55, and 57-60
`
`Kiuchi is a printed publication presented at the 1996 Symposium on
`
`Network and Distributed Systems Security (SNDSS) on February 22 & 23, 1996,
`
`and published by IEEE in the Proceedings of SNDSS 1996. See Ex. 1018. Kiuchi
`
`10
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`is prior art to the ‘211 patent at least under § 102(b), regardless of which effective
`
`filing date in the priority chain is applied to the claims.
`
`Overview of Kiuchi
`
`Kiuchi describes a system and a protocol called “C-HTTP” that “provides
`
`secure HTTP communication mechanisms within a closed group of institutions on
`
`the Internet, where each member is protected by its own firewall.” Ex. 1018 at p.
`
`64, abstract; see Ex. 1021 at ¶ 16. As an example, Kiuchi describes that for
`
`“hospitals and related institutions,” there is a need for “[s]ecure transfer of patient
`
`information” between hospitals, and that “medical information has to be shared
`
`among some hospitals, but it should not be made available to other sites.” Ex. 1018
`
`at p. 64, § 5; see Ex. 1021 at ¶ 16. Kiuchi describes that the C-HTTP protocol
`
`allows members of different institutions to communicate using “secure HTTP
`
`communication mechanisms” by way of intermediate proxies that are associated
`
`with each institution. Ex. 1018 at p. 64, Abstract; see Ex. 1021 at ¶ 16. The
`
`following Diagram 1 illustrates relevant parts within the C-HTTP system described
`
`by Kiuchi, and will be used to describe the C-HTTP system. See Ex. 1021 at ¶ 16.
`
`
`
`
`
`
`
`
`
`11
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`
`
`
`
`
`
`
`
`
`
`
`
`(Diagram 1)
`
`In particular, Kiuchi describes a process by which a client-side proxy, in one
`
`institution, establishes a secure C-HTTP connection with a server-side proxy, in
`
`another institution, using the C-HTTP protocol over the Internet. See Ex. 1018 at p.
`
`64, § 2.1; p. 69, § 5; see also Ex. 1021 at ¶ 17. The C-HTTP connection uses
`
`encryption to provide a secure connection. Ex. 1018 at p. 64 §§ 2.1, 2.2; see Ex.
`
`1021 at ¶ 17. Through the secure C-HTTP connection, a user agent associated with
`
`the client-side proxy may request information stored on one or more origin servers
`
`associated with the server-side proxy. See id. In order to establish a C-HTTP
`
`connection, Kiuchi teaches discrete steps that are described in the following block
`
`diagram. See Ex. 1018 at pp. 65-66, § 2.3; see also, Ex. 1021 at ¶ 17, Diagram 2,
`
`where each step is numbered to indicate a temporal sequence of the steps taught by
`
`Kiuchi.
`
`
`
`12
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`(Diagram 2)
`
`In Kiuchi, the user agent can display HTML documents to an end-user. See
`
`Ex. 1018 at p. 65, § 2.3; see also Ex. 1021 at ¶ 18. Through interaction with the
`
`user agent, the end user may, for example, select a hyperlink URL included within
`
`an HTML document. See id. Kiuchi provides an example of the selected URL:
`
`“http://server.in.current.connection/sample.html=@=6zdDfldfcZLj8V!i”, where
`
`“server.in.current.connection” is the hostname, “sample.html” is the name of the
`
`resource being requested, and “6zdDfldfcZLj8V!i” is a connection ID. See Ex.
`
`1018 at p. 65, § 2.3; see also Ex. 1021 at ¶ 18.
`
`Diagram 3 illustrates the initial steps performed by Kiuchi’s system after the
`
`user selects the hyperlink (assuming that no C-HTTP connection exists). See Ex.
`
`1021 at ¶ 19. These steps include: (1) a request sent from the user agent to the
`
`client-side proxy for the selected URL; (2) a request from the client-side proxy to
`
`13
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`the C-HTTP name server for an IP address corresponding to the hostname included
`
`in the selected URL; and (3) a response from the C-HTTP name server to the
`
`client-side proxy that either includes the IP address associated with the server-side
`
`proxy or an error message. Ex. 1018 at 65-66; see Ex. 1021 at ¶ 19. In the last step,
`
`if the C-HTTP name server returns the IP address of the server-side proxy, then the
`
`client-side proxy begins a C-HTTP connection with the server-side proxy, and
`
`otherwise, in case of an error message, the client-side proxy performs a DNS
`
`lookup using the standard/public DNS, as illustrated by the dashed line in Diagram
`
`3, below. See Ex. 1018 at p. 65, § 2.3; see also Ex. 1021 at ¶ 19.
`
`(Diagram 3)
`
`
`
`Analyzing these steps in further detail, when the end user selects the
`
`hyperlink in the displayed HTML document, the user agent sends a request for the
`
`selected URL to the client-side proxy, as illustrated by arrow (1) in Diagram 3. See
`
`Ex. 1018 at p. 65, § 2.3; see also Ex. 1021 at ¶ 20. When the client-side proxy
`
`14
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`receives the URL (including a hostname) from the user agent, in some cases, the
`
`client-side proxy attempts to establish a new connection with the host
`
`corresponding to the hostname included in the URL. See id.
`
`To establish a new connection with the host, the client-side proxy sends a
`
`request, as illustrated by arrow (2) in Diagram 3, to resolve the hostname included
`
`in the URL. See Ex. 1018 at p. 65, § 2.3(2); see also Ex. 1021 at ¶ 21. In some
`
`instances, the hostname corresponds to an origin server behind a server-side proxy
`
`and is associated with the IP address of the server-side proxy. Ex. 1018 at p. 65, §
`
`2.3; see Ex. 1021 at ¶ 21. In other instances, the hostname instead corresponds to a
`
`server on the Internet outside the C-HTTP network. Ex. 1018 at p. 65, § 2.3; see
`
`Ex. 1021 at ¶ 21.
`
`Upon receipt of the request from the client-side proxy (arrow (2)), the C-
`
`HTTP name server first authenticates the client-side proxy to determine if the
`
`request is legitimate. Ex. 1018 at p. 65, § 2.3; see also Ex. 1021 at ¶ 23. For
`
`example, Kiuchi describes that the communication between the client-side proxy
`
`and the C-HTTP name server is certified. See Ex. 1018 at p. 65; see also Ex. 1021
`
`at ¶ 23. In particular, the client side proxy signs a request before sending it to the
`
`C-HTTP name server, which then verifies the signature in the request using a
`
`public key. Id. If successful, the C-HTTP name server authenticates the request as
`
`being legitimate. Id. When the request is legitimate, the C-HTTP name server
`
`15
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`determines whether the “server-side proxy [associated with the hostname] is
`
`registered in the closed network.” Id.
`
`If the C-HTTP name server confirms that the server-side proxy is not
`
`registered in the closed network, or if the connection otherwise is not permitted,
`
`then the C-HTTP name server returns an error message, in response to which the
`
`client-side proxy performs a look-up with a standard/public DNS server, behaving
`
`like an ordinary HTTP proxy (as illustrated by the dashed line in Diagram 3). See
`
`Ex. 1018 at p. 65; see also Ex. 1021 at ¶ 24. The standard/public DNS server then
`
`returns to the client-side proxy an IP address of the host that corresponds to the
`
`hostname, which the client-side proxy uses to connect to the host on behalf of the
`
`user agent. Id.
`
`On the other hand, if the C-HTTP name server confirms that the server-side
`
`proxy is registered in the closed network and is permitted to accept a connection
`
`from the client-side proxy, then the C-HTTP name server sends a response to the
`
`client-side proxy’s request that includes “the IP address and public key of the
`
`server-side proxy and both request and response Nonce values,” as illustrated by
`
`arrow (3) in Diagram 3. Ex. 1018 at p. 65, § 2.3; see Ex. 1021 at ¶ 25. The client-
`
`side proxy then uses the IP address, public key, and request Nonce values to
`
`contact the server-side proxy and create a C-HTTP connection with the server-side
`
`proxy. Id. The steps for doing so are illustrated in Diagram 4. See Ex. 1021 at ¶ 25.
`
`16
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`In particular, Kiuchi describes that the client-side proxy, in response to
`
`receiving the IP address and public key of the server-side proxy, sends a “[r]equest
`
`for connection to the server-side proxy” that includes a symmetric key and other
`
`information (indicated by arrow (4) in Diagram 4). Ex. 1018 at pp. 65-66, § 2.3,
`
`steps 3-5; see Ex. 1021 at ¶ 26. The server-side proxy then performs a “[l]ookup of
`
`client-side proxy information” with the C-HTTP name server to determine if the
`
`client-side proxy is authorized to access the server-side proxy (arrows 5 and 6). Id.
`
`If the client-side proxy is authorized, then the server-side proxy sends confirmation
`
`of the C-HTTP connection to the client-side proxy (arrow 7). Id.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`(Diagram 4)
`
`Considering these steps in further detail, the client-side proxy, in response to
`
`receiving the IP address and associated information from the C-HTTP name server,
`
`sends a request for connection to the server-side proxy, as illustrated by arrow (4)
`
`17
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`in Diagram 4. See Ex. 1018 at p. 65, § 2.3; see also Ex. 1021 at ¶ 27. After
`
`receiving the request, the server-side proxy “asks the C-HTTP name server
`
`whether the client-side proxy is an appropriate member of the closed network,” as
`
`illustrated by arrow (5) in Diagram 4, and, in response, the C-HTTP name server
`
`“examines whether the client-side proxy is permitted to access to the server-side
`
`proxy.” Ex. 1018 at pp. 65-66, § 2.3; see Ex. 1021 at ¶ 27. If the C-HTTP name
`
`server determines that “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, as illustrated by arrow (6) in Diagram 4.
`
`Ex. 1018 at p. 66, § 2.3; see Ex. 1021 at ¶ 27. The server-side proxy then responds
`
`to the client-side proxy with a message that contains a symmetric key and other
`
`information, thereby establishing the C-HTTP connection. Id.
`
`Subsequently, a user agent (in the same institution as the client-side proxy)
`
`is able to securely access an origin server (in the same institution as the server-side
`
`proxy) using the C-HTTP connection. Ex. 1018 at p. 66, § 2.3; see Ex. 1021 at ¶ 28
`
`As a result, members of different institutions on the Internet can communicate, via
`
`client-side and server-side proxies, using “secure HTTP communication
`
`mechanisms.” Ex. 1018 at p. 64, Abstract; Ex. 1021 at ¶ 28.
`
`Kiuchi further explains that “end-users…do not even have to be conscious of
`
`using C-HTTP based communications” and that “C-HTTP is transparent to both”
`
`18
`
`

`

`Petition for Inter Partes Review of U.S. Patent No. 7,921,211
`
`the user agent and the origin server. Ex. 1018 at p. 68, § 4.2; Ex. 1021 at ¶ 32. In
`
`particular, Kiuchi explains that, “[f]rom the view of the user agent or client-side
`
`proxy, all resources appear to be located in a server-side proxy on the firewall.”
`
`Ex. 1018 at p. 66, § 2.3; Ex. 1021 at ¶ 32.
`
`Furthermore, within each institution, Kiuchi describes that “each member is
`
`protected by its own firewall.” Ex. 1018 at p. 64, abstract; see Ex. 1021 at ¶ 33. As
`
`an example, Kiuchi describes that “in-hospital networks are usually protected using
`
`a dual home gateway and packet filter (firewall).” Ex. 1018 at p. 67, § 4.2; Ex.
`
`1021 at ¶ 33. In addition to the protection offered by the firewall within each
`
`institution, for further security, Kiuchi describes that “it is possible to develop C-
`
`HTTP proxies which can communicate with other secure HTTP compatible user
`
`agents and servers.” Ex. 1018 at p. 69, § 4.4; Ex. 1021 at ¶ 33. Kiuchi explains that
`
`this configuration can “assure end-to-end or individual security.” Id.
`
`In addition, Kiuchi explains t