IPR2015

Paper No. 1

UNITED STATES PATENT AND TRADEMARK OFFICE

____________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD

____________________

APPLE INC.

Petitioner, v.

VIRNETX, INC. AND SCIENCE APPLICATION INTERNATIONAL

CORPORATION,

Patent Owner.

Patent No. 8,843,643

Issued: September 23, 2014

Filed: July 25, 2013

Inventors: Victor Larson, et al.

Title: SYSTEM AND METHOD EMPLOYING AN AGILE NETWORK

PROTOCOL FOR SECURE COMMUNICATIONS USING SECURE DOMAIN

NAMES

____________________

Inter Partes Review No. IPR2015-01009

__________________________________________________________________

Petition for Inter Partes Review of

U.S. Patent No. 8,843,643

Table of Contents

I.

Introduction ................................................................................................. 1

A.

Certification the ’643 Patent May Be Contested by Petitioner ...... 1

B.

Fee for Inter Partes Review (§ 42.15(a)) .......................................... 1

C.

Mandatory Notices (37 CFR § 42.8(b)) ............................................ 1

1.

Real Party in Interest (§ 42.8(b)(1)) .......................................... 1

2.

Other Proceedings (§ 42.8(b)(2)) ............................................... 2

3.

Lead and Backup Lead Counsel (§ 42.8(b)(3)) ......................... 2

4.

Service Information (§ 42.8(b)(4)) ............................................ 3

5.

Proof of Service (§§ 42.6(e) and 42.105(a)) .............................. 3

II.

Identification of Claims Being Challenged (§ 42.104(b)) .......................... 3

III.

Relevant Information Concerning the Contested Patent .......................... 3

A.

Overview of the ’643 Patent .............................................................. 3

1.

The ’643 Patent Specification .................................................... 3

2.

Representative Claims ............................................................... 5

B.

Effective Filing Date .......................................................................... 5

C.

The Person of Ordinary Skill in the Art .......................................... 7

D.

Claim Construction ........................................................................... 7

1.

“encrypted communication link” ............................................... 8

2.

“domain name” ........................................................................ 10

3.

“constructing a domain name” ................................................ 10

4.

“secure domain name” / “non-secure domain name” .............. 11

5.

“secure domain name service (SDNS)” ................................... 12

6.

“virtual private network communication link” ........................ 12

7.

“one encrypted communication link in a hierarchy of a plurality of encrypted communication links” ......................................... 13

IV.

Analysis of the Patentability of the ’643 Patent ....................................... 14

A.

Summary of Prior Art to the ’643 Patent ...................................... 15 ii

1.

Overview of Windows Resource Kit (Ex. 1005) ..................... 15

2.

Overview of IE5 Resource Kit (Ex. 1006) .............................. 17

3.

Overview of Elgamal (Ex. 1007) ............................................. 18

B.

Windows Resource Kit (Ex. 1005) Anticipates Claims 1-9, 12, 14,

17-24, 27, and 29 .............................................................................. 19

1.

Independent Claims 1 and 17 Are Anticipated ........................ 19 a) Claim 1 Preamble .......................................................... 19 b) “enabl[e/ing]. . . a secure communication mode without a user entering any cryptographic information for establishing the . . . mode . . .” ...................................... 20 c) “establishing, based on a determination that the secure communication mode has been enabled, the encrypted communication link between the first device and the second device over the communication network, the establishing including” .................................................. 22 d) “construct[ing] a domain name based on an identifier associated with the second device” ............................... 23 e) “send[ing] a query using the domain name” .................. 27 f) “receiv[e/ing], in response to the query, at least one network address associated with the domain name” ..... 28 g) “initiat[e/ing] establishment of the encrypted communication link between the first device and the second device over the communication network using the at least one network address and encrypted communication link resources received from a server that is separate from the first device” ................................... 28 h) Additional System Elements of Claim 17 ..................... 30

2.

Claims 2, 4, and 18 Are Anticipated ........................................ 31 a) Claim 2 “wherein enabling the secure communication mode includes receiving a command entered into the first device by the user, and the command specifies the secure communication mode” .................................................. 32 b) Claim 4 “displaying, at the first device, a user interface including a user interface element for enabling the secure iii

communication mode; and receiving the command from the user via the user interface element.” ........................ 33 c) Claim 18 ........................................................................ 34

3.

Claims 3 and 19 Are Anticipated ............................................ 36

4.

Claims 5, 6, 20, and 21 Are Anticipated .................................. 37

5.


6.


7.


8.

Claims 12 and 27 Are Anticipated ........................................... 41

9.

Claims 14 and 29 Are Anticipated ........................................... 44

C.

Windows Resource Kit (Ex. 1005) In View of IE5 Resource Kit

(Ex. 1006) and Elgamal (Ex. 1007) Renders Obvious Claims 1, 13,

15-17, 28, and 30-32 ......................................................................... 45

1.

Combining Windows Resource Kit and IE5 Resource Kit and

Elgamal ................................................................................... 45

2.

Claims 1 and 17 Would Have Been Obvious over Windows

Resource Kit in View of IE5 Resource Kit and Elgamal ......... 47 a) Claim 1 Preamble .......................................................... 48 b) “enabl[e/ing]. . . a secure communication mode without a user entering any cryptographic information for establishing the . . . mode . . .” ...................................... 48 c) “establishing, based on a determination that the secure communication mode has been enabled, the encrypted communication link between the first device and the second device over the communication network, the establishing including” .................................................. 49 d) “construct[ing] a domain name based on an identifier associated with the second device” ............................... 50 e) “send[ing] a query using the domain name” .................. 50 f) “receiv[e/ing], in response to the query, at least one network address associated with the domain name” ..... 51 g) “initiat[e/ing] establishment of the encrypted communication link between the first device and the iv

second device over the communication network using the at least one network address and encrypted communication link resources received from a server that is separate from the first device” ................................... 51 h) Additional System Elements of Claim 17 ..................... 52

3.

Claims 13 and 28 Would Have Been Obvious ........................ 54

4.


5.


6.

Claim 30 Would Have Been Obvious ..................................... 59

D.

No Secondary Considerations Exist ............................................... 59

V.

Conclusion .................................................................................................. 60 v

Petition in IPR2015-01009

I.

Introduction

A.

Certification the ’643 Patent May Be Contested by Petitioner

Petitioner certifies that U.S. Patent No. 8,843,643 (Ex. 1001) (the ’643 patent) is available for inter partes review. Petitioner also certifies it is not barred or estopped from requesting inter partes review of the claims of the ’643 patent.

Neither Petitioner, nor any party in privity with Petitioner, has filed a civil action challenging the validity of any claim of the ’643 patent. The ’643 patent has not been the subject of a prior inter partes review by Petitioner or a privy of Petitioner.

Petitioner also certifies this petition for inter partes review is timely filed as it has never been asserted against Petitioner in litigation. Thus, because there is no patent owner’s action, this petition complies with 35 U.S.C. § 315(b). Petitioner also notes that the timing provisions of 35 U.S.C. § 311(c) and 37 C.F.R.

§ 42.102(a) do not apply to the ’643 patent, as it pre-dates the first-to-file system.

See Pub. L. 112-274 § 1(n), 126 Stat. 2456 (Jan. 14, 2013).

B.

Fee for Inter Partes Review (§ 42.15(a))

The Director is authorized to charge the fee specified by 37 CFR § 42.15(a) to Deposit Account No. 50-1597.

C.

Mandatory Notices (37 CFR § 42.8(b))

1.

Real Party in Interest (§ 42.8(b)(1))

The real party in interest of this petition pursuant to § 42.8(b)(1) is Apple

Inc. (“Apple”) located at One Infinite Loop, Cupertino, CA 95014.

1


2.

Other Proceedings (§ 42.8(b)(2))

IPR2015-01010 filed concurrently also involves the ’643 patent. Each petition advances unique grounds and are based on different primary references.

IPR2015-01010 challenges claims 1-9, 11-24, and 27-32 of the ’643 patent on obviousness grounds based on Yeager (Ex. 1008). While both petitions rely on

IE5 Resource Kit (Ex. 1006) as a secondary reference, each relies on different features described in that reference. For example, with respect to the independent claims, IPR2015-01009 presents grounds in which IE5 Resource Kit teaches the claimed “ constructing ” step, while in IPR2015-01010, grounds are presented in which IE5 Resource Kit is provided primarily for its explanation of SSL to the person of skill in relation to the claimed “ enabling ” and “ initiating establishment of the secure communication link ” steps. The present petition and IPR2015-01010 present unique correlations of the challenged ’643 claims to the prior art, and each warrants independent institution of trial. Petitioner respectfully requests the Board institute each petition, as each presents distinct and non-redundant grounds.

3.

Lead and Backup Lead Counsel (§ 42.8(b)(3))

Lead Counsel is: Jeffrey P. Kushan (Reg. No. 43,401), jkushan@sidley.com,

(202) 736-8914. Back-Up Lead Counsel are: Scott Border ( pro hac to be requested), sborder@sidley.com, (202) 736-8818; and Thomas A. Broughan III

(Reg. No. 66,001), tbroughan@sidley.com, (202) 736-8314.

2


4.

Service Information (§ 42.8(b)(4))

Service on Petitioner may be made by e-mail (iprnotices@sidley.com), mail or hand delivery to: Sidley Austin LLP, 1501 K Street, N.W., Washington, D.C.

20005. The fax number for lead and backup lead counsel is (202) 736-8711.

5.

Proof of Service (§§ 42.6(e) and 42.105(a))

Proof of service of this petition is provided in Attachment A .

II.

Identification of Claims Being Challenged (§ 42.104(b))

Claims 1-9, 12-24, 27-32 of the ’643 patent are unpatentable as being anticipated and/or obvious under 35 U.S.C. §§ 102-103 as follows: (i) Claims 1-9,

12, 14, 17-24, 27, and 29 are anticipated under 35 U.S.C. § 102(a) by Microsoft

Windows 2000 Professional Resource Kit (“Windows Resource Kit”) (Ex. 1005); and (ii) Claims 1, 13, 15-17, 28, and 30-32 are obvious under 35 U.S.C. § 103 based on Windows Resource Kit in view of Internet Explorer 5 Resource Kit (“IE5

Resource Kit”) (Ex. 1006) and further in view of United States Patent No.

5,657,390 (“Elgamal”) (Ex. 1007). A list of evidence relied upon in this petition is set forth in Attachment B .

III.

Relevant Information Concerning the Contested Patent

A.

Overview of the ’643 Patent

1.

The ’643 Patent Specification

The ’643 patent is a member of a family of patents issued to Larson et al., including, inter alia , U.S. Patent Nos. 6,502,135 (“ ’135 patent”), 7,188,180

3


(“ ’180 patent”), 7,418,504 (“ ’504 patent”), 7,490,151 (“ ’151 patent”), 7,921,211

(“ ’211 patent”), 7,987,274 (“ ’274 patent”), 8,051,181 (“ ’181 patent”), 8,504,697

(“ ’697 patent”), 6,839,759 (“ ’759 patent”), 8,868,705 (“ ’8705 patent”),

8,850,009 (“ ’009 patent”), 8,458,341 (“ ’341 patent”), 8,516,131 (“ ’131 patent”), and 8,560,705 (“ ’0705 patent”).

The ’643 patent disclosure, like other members of this patent family, is largely focused on techniques for securely communicating over the Internet using the “Tunneled Agile Routing Protocol” (“TARP”). Ex. 1001 at 3:20-23. The ’643 patent explains that TARP allows for secure and anonymous communications by using tunneling, an IP address hopping scheme where the IP addresses of the end devices and routers participating in the system can change over time, and a variety of other security techniques. Ex. 1001 at 1:38-40, 3:20-6:13.

The ’643 patent also includes one section—added in an April 2000 continuation-in-part application—directed to a “One-Click” embodiment. Ex.

1001 at 6:42-7:16, 49:20-53:30; see § III.B, below; Ex. 1003 at ¶¶ 40-46. This embodiment refers to a technique for enabling a secure communication link using a single click of a mouse or as a default setting on boot-up (i.e., no click). Ex. 1001 at 49:23-44. Specifically, a “go secure” hyperlink is discussed that, when clicked, does not require the user to enter any user identification information, passwords or encryption keys to establish a secure communication link. Ex. 1001 at 49:50-64,

4


50:33-38. The embodiment then establishes a secure communication transparently to the user. Ex. 1001 at 50:40-43; Ex. 1003 at ¶¶ 45-46.

2.

Representative Claims

Independent claims 1 and 17 of the ’643 patent define a method and a device, respectively, but recite the same operative steps. See Ex. 1001 at 55:46-67,

57:12-37. Claim 1 is representative, specifying a method wherein a first device and a second device establish an encrypted communication link by: (1) enabling a secure communication mode at the first device without the user entering any cryptographic information; (2) determining that the secure communication mode has been enabled and establishing the encrypted communication link by (i) constructing a domain name for the second device based on an identifier; (ii) sending a query using the constructed domain name; and (iii) receiving a network address in response to the query; and (iv) initiating establishment of the encrypted communication link using the network address and encrypted communication link resources received from a server other than the first device.

B.

Effective Filing Date

The ’643 patent issued from U.S. Appl. No. 13/950,919 (“the ’919 application”). The ’919 application claims the benefit as a continuation of the following applications: 13/903,788, filed May 28, 2013; 13/336,790 (issued as

U.S. Patent No. 8,458,341); 13/049,552 (issued as U.S. Patent No. 8,572,247);

5


11/840,560 (issued as the ’211 patent); 10/714,849 (issued as the ’504 patent); and

09/558,210 (the ’210 application), filed April 26, 2000, and now abandoned. The

’919 application is also designated as a continuation-in-part of application

09/504,783, filed on February 15, 2000 (issued as the ’135 patent), which is a continuation-in-part of application 09/429,643, filed on October 29, 1999. The

’210, ’783 and ’9643 applications claim priority to applications 60/106,261, filed

October 30, 1998 and 60/137,704, filed June 7, 1998.

Claims 1 and 17 of the ’643 patent are independent claims. Claims 2-16 depend directly or indirectly from claim 1 , and claims 18-32 depend directly or indirectly from claim 17 . Claims 2-16 and 18-32 cannot enjoy an effective filing date earlier than that of claims 1 and 17, respectively, from which they depend.

Claims 1 and 17 of the ’643 patent rely on the “One-Click” disclosure first added on April 26, 2000 in the ’210 application. For example, claims 1 and 17 of the ’643 patent both specify enabling “ a secure communication mode without a user entering any cryptographic information ” and “ constructing a domain name based on an identifier associated with the second device.

” No application filed prior to the ’210 application provides a written description of these features, much less devices or methods corresponding to the ’643 claims. Compare Ex. 1037

(’210 application’s original specification) at 76-88 (discussing “One-Click Secure

On-line Communications”) with Ex. 1015 (’210 application’s parent, the ’135

6

Petition in IPR2015-01009 patent) at 44:14-47:18 (making no mention of “One-Click” communications); Ex.

1003 at ¶¶ 40-42. In reexamination proceedings involving related U.S. Patent No.

6,839,759 (Ex. 1016), Patent Owner has not disputed that “ enabling a secure communication mode without a user entering any cryptographic information ” has no support in the ’135 patent, and thus claims employing this element cannot have an effective filing date prior to April 26, 2000. See Ex. 1010 at 7-8; Ex. 1011 at 1-

60; Ex. 1003 at ¶ 43. Accordingly, the effective filing date of the ’643 patent claims is no earlier than April 26, 2000 .

C.

The Person of Ordinary Skill in the Art

A person of ordinary skill in the art in the field of the ’643 patent would have been someone with a good working knowledge of networking protocols, including those employing security techniques, as well as computer systems that support these protocols and techniques. The person also would be very familiar with Internet standards related to communications and security, and with a variety of client-server systems and technologies. The person would have gained this knowledge either through education and training, several years of practical working experience, or through a combination of these. Ex. 1003 ¶ 82.

D.

Claim Construction

In this proceeding, claims must be given their broadest reasonable construction in light of the specification. 37 CFR § 42.100(b). The ’643 patent

7

Petition in IPR2015-01009 shares a common disclosure and uses several of the same terms as the ’697, ’274,

’180, ’151, ’504, ’211, and ’759 patents for which Patent Owner has advanced constructions pertinent to the claims at issue here. If Patent Owner contends that terms in the ’643 patent claims should be read as having a special meaning, those contentions should be disregarded unless Patent Owner also amends the claims compliant with 35 U.S.C. § 112 to make them expressly correspond to those contentions. See 77 Fed. Reg. 48764 at II.B.6 (August 14, 2012); cf. In re Youman ,

679 F.3d 1335, 1343 (Fed. Cir. 2012). In the constructions below, Petitioner identifies representative subject matter within the scope of the claims, read with their broadest reasonable interpretation. Petitioner expressly reserves its right to advance different constructions in any district court litigation, which employs a different claim construction standard.

1.

“encrypted communication link”

Each independent claim recites the term “ encrypted communication link .”

The ’643 patent does not define “encrypted communication link.” The Board has not interpreted this term in proceedings involving related patents, but has construed the terms “ secure communication link” and “ virtual private network communication link.” Specifically, in IPR2014-00237 involving the related ’697 patent, the Board interpreted “secure communication link” to mean “a transmission path that restricts access to data, addresses, or other information on the path,

8

Petition in IPR2015-01009 generally using obfuscation methods to hide information on the path, including, but not limited to, one or more of authentication, encryption, or address hopping.”

Paper 15 at 10 (May 4, 2014).

Like the ’697 patent claims, the ’643 patent claims specify communication over a “communication link,” but the ’643 claims specify the link is “encrypted.”

Both patents generally claim DNS-based methods and systems for establishing secure communications or VPNs. The common specification explains that the

DNS-based VPN scheme permits computers to privately communicate with each other over a public network by protecting their anonymity. See Ex. 1001 at 39:41-

57. In other words, the “communication link” resulting from implementation of the claimed DNS-based methods and systems must be “a transmission path that restricts access to data, addresses, or other information on the path, including, but not limited to, one or more of authentication, encryption, or address hopping.” Ex.

1003 at ¶¶ 56-58; see also IPR2014-00237, Paper 15 at 10 (May 4, 2014);

IPR2014-00481, Paper 11 at 6-7 (Sept. 3, 2014). The additional term “encrypted” limits the range of these communication links to those that at least employ encryption to secure the communications. Ex. 1003 at ¶ 59. The broadest reasonable interpretation of “ encrypted communication link ” is “ a transmission path that restricts access to data, addresses, or other information on the path at least by using encryption .” Ex. 1003 at ¶¶ 56-60.

9


2.

“domain name”

Each independent claim recites the term “ domain name .” Although the

’643 patent does not define the term, a “ domain name ” would be understood by a person of ordinary skill to be a hierarchical sequence of words in decreasing order of specificity that corresponds to a numerical IP address. Ex. 1003 at ¶ 61. Patent

Owner has advanced a more general description in other proceedings; namely, “a name corresponding to an IP address.” See, e.g.

, Ex. 1012 at 14-15. Both definitions are reasonable; thus the broadest reasonable interpretation of “domain name” is “ a name corresponding to an IP address .” Ex. 1003 at ¶ 61-63.

3.

“constructing a domain name”

Each independent claim specifies “ constructing a domain name .” The ’643 patent does not define the term “ constructing ” as it relates to domain names.

Elsewhere, the '643 patent uses the term “constructing” in a manner consistent with its plain and ordinary meaning, namely, preparing a representation (e.g., a string) of a domain name. See e.g.

, Ex. 1001 at 11:22-39 (“to construct a series of TARP packets . . . To create a packet . . .”), 12:49-53 (“To form a normal IP packet 360 .

. . constructing the TARP packet 360 . . .”) (emphasis added); Ex. 1003 at ¶ 64.

This meaning also encompasses the only discussion of something that could be described as “constructing” a domain name in the ‘643 patent; namely:

“replac[ing] the top-level domain name . . . with a secure top-level domain name.”

10


Ex. 1001 at 50:23-25; Ex. 1003 at ¶ 65. The broadest reasonable construction of

“ constructing a domain name ” thus is any technique for creating a representation of a domain name. Ex. 1003 at ¶¶ 64-66.

4.

“secure domain name” / “non-secure domain name”

Dependent claims 12 and 27 recite the terms “ secure domain name ” and

“ non-secure domain name .” In a related proceeding involving the ’180 patent which shares substantial portions of the ’643 patent disclosure, the Board found “a

‘secure domain name’ is a name that corresponds to a secure computer network address.” IPR2015-00481, Paper 11 at 8 (Sept. 3, 2014). This is consistent with the ’643 patent’s disclosure. Ex. 1003 at ¶¶ 67-69.

For example, the specification describes a “secure domain name” as a domain name that corresponds to the secure network address of a secure server

3320. See Ex. 1001 at 51:6-28. The ’643 patent also describes evaluating domain names in DNS requests to determine whether access to a secure site has been requested. Id.

at 40:1-7. The disclosure also explains that “[e]ach secure computer network address is based on a non-standard top-level domain name, such as .scom,

.sorg, .snet, .sedu, .smil and .sint.” Id.

at 7:43-46. In the context of the ’643 patent, one of ordinary skill would understand a “secure computer network address” to include a network address for a secure computer or service, or an address in a secure computer network. Ex. 1003 at ¶¶ 67-69. Accordingly, the

11

Petition in IPR2015-01009 broadest reasonable interpretation of “ secure domain name ” would be “ a name that corresponds to a secure computer network address ,” and the broadest reasonable interpretation of a “ non-secure domain name ” would be “ a name that corresponds to a non-secure computer network address .” Ex. 1003 at ¶¶ 67-70.

5.

“secure domain name service (SDNS)”

Dependent claims 7 and 22 recite a “ secure domain name service (SDNS) .”

In a related proceeding involving the ’180 patent, the Board found “a ‘secure domain name service’ is a service that provides a secure computer network address for a requested secure domain name.” IPR2015-00481, Paper 11 at 9 (Sept. 3,

2014). This construction also is consistent with the ’643 patent disclosure. For example, the specification explains that an SDNS “stores a computer network address corresponding to” a secure domain name, and that users can query the

SDNS to obtain the secure computer network address. Ex. 1001 at 51:6-28; Ex.

1003 at ¶¶ 71-73. The broadest reasonable interpretation of a “ secure domain name service (SDNS) ” would therefore be “ a service that provides a secure computer network address for a requested secure domain name .”

6.

“virtual private network communication link”

Dependent claims 14 and 29 specify that the encrypted communication link

“comprises a virtual private network communication link .” The ’643 patent does not provide an explicit definition for “virtual private network communication link.”

12


In IPR2014-00481 involving the related ’180 patent, the Board interpreted “virtual private network communication link” to mean “a transmission path between two devices 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.”

Paper 11 at 6-7 (Sept. 3, 2014). The Board also read the ’180 patent as employing various levels of security in a VPN that do not require encryption, such as authentication, or information or address hopping. Id.

at 7.

The construction used for the ’180 patent is consistent with the ’643 specification, which explains that “software module 3309 accesses secure server

3320 through VPN communication link 3321” and the communication link 3321 is shown as only the portion of the path between computer 3301 and server 3320 that is over network 3302. Ex. 1001 at 51:57-58, Fig. 33; Ex. 1003 at ¶¶ 74-76.

Accordingly, the broadest reasonable interpretation of “virtual private network communication link” is “ a transmission path between two devices 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 .” Ex. 1003 at

¶¶ 74-77.

7.

“one encrypted communication link in a hierarchy of a plurality of encrypted communication links”

13


Dependent claim 30 recites “ one encrypted communication link in a hierarchy of a plurality of encrypted communication links .” The ’643 patent does not define this term, but provides several examples of sets of “hierarchical” encrypted communication links: “different priority level[s] of access” (Ex. 1001 at

51:14-17), “different levels of security” ( id.

at 40:51-64), and different “layers of encrypt[ion]” ( id.

at 2:29-46). One of ordinary skill in the art would understand a hierarchy in the context of the ’643 patent to mean either a ranked or graded set of encrypted communication links ( e.g.

, different priority levels or levels of security), or a nested set of encrypted communication links ( e.g.

, multiple layers of encryption). Ex. 1003 at ¶¶ 78-79. The broadest reasonable interpretation of “ one encrypted communication link in a hierarchy of a plurality of encrypted communication links ” is therefore “ one encrypted communication link in a ranked, graded, or nested set of a plurality of encrypted communication links .”

Ex. 1003 at ¶¶ 78-80.

IV.

Analysis of the Patentability of the ’643 Patent

The ’643 patent has two independent claims (claims 1 and 17), each of which specifies the same operative steps. See § III.A.2. Claim 1 is representative, and as explained above, defines a process where a first network device communicates with a second network device via an encrypted communication link that is established via constructing a domain name, looking up the address for that

14

Petition in IPR2015-01009 domain name, and making an encrypted connection to that address.

A.

Summary of Prior Art to the ’643 Patent

1.

Overview of Windows Resource Kit (Ex. 1005)

Microsoft Windows 2000 Professional Resource Kit (“Windows Resource

Kit”) (Ex. 1005) is a “comprehensive technical resource for installing, configuring, and supporting” the Windows 2000 operating system. Ex. 1005 at xxxiii.

Windows Resource Kit was published on February 2, 2000 by Microsoft

Press, see, e.g

., Ex. 1014 at 1, and is therefore prior art to the ’643 patent under 35

U.S.C. § 102(a). Additional evidence of the publication of Windows Resource Kit includes its copyright registration—a record submitted to and completed by the

United States Copyright Office that is also signed by a representative of the publisher of Windows Resource Kit. Ex. 1009 at 1-2. Its copyright registration states that Windows Resource Kit has a publication date of February 2, 2000. See id.

; CA, Inc. v. Simple.com, Inc.

, 780 F.Supp.2d 196, 307-308 (E.D. NY Mar. 5,

2009) (copyright certificate is prima facie evidence that reference is a printed publication under § 102 as of the specified publication date (citing 17 U.S.C. §

410(c) and Ex Parte Research and Mfg. Co.

, 1989 Pat. App. LEXIS 2, at *12–15

(B.P.A.I. Mar. 9, 1989))). Prior to the effective filing date of the ’643 patent, interested members of the public could purchase Windows Resource Kit from bookstores and directly from Microsoft. See, e.g., Ex. 1019 at 2, 5. And they

15

Petition in IPR2015-01009 would have been able to find Windows Resource Kit with a reasonable search. For example, Microsoft Press advertised Windows Resource Kit before the effective filing date of the ’643 patent. See, e.g., Ex. 1019. That persons of skill in the art could discover and obtain Windows Resource Kit prior to the effective filing date of the ’643 patent is confirmed by the actual receipt of the book by members of the public. See, e.g., Ex. 1017 at 3 (March 24, 2000 review); Ex. 1018 at 2 (April 18,

2000 review).

One pertinent aspect of the disclosure of Windows Resource Kit’s disclosure is its description of the domain name resolution functionality in a computer running Windows 2000. Ex. 1003 at ¶¶ 160-175. Windows Resource Kit teaches that if an application wishes to communicate with another computer, a local DNS resolver component on the first computer receives a DNS request from the application, sends a query containing domain names to DNS servers, and receives responses from those DNS servers containing the IP addresses corresponding to the queried domain name. Ex. 1005 at 964-965. Windows Resource Kit explains that in various scenarios, the Windows 2000 resolver constructs a domain name by adding a “domain name suffix” to a host name. Id ; Ex. 1005 at 964 (Fig. 22.2),

974 (Fig. 22.5), 975 (Fig. 22.6).

Another pertinent aspect of Windows Resource Kit’s disclosure is its description of IP Security functionality. Ex. 1003 at ¶¶ 176-203. Windows

16


Resource Kit discloses that IP Security can be enabled using security policies. Ex.

1005 at 1020. A user is not required to enter any information such as encryption keys in order to enable these policies, but simply chooses the desired policy in the

IP Security dialog window. Ex. 1005 at 1024-1025.

The operation and features of Windows Resource Kit are explained in greater detail in Ex. 1003 at ¶¶ 155-203, and below with respect to the claims.

2.

Overview of IE5 Resource Kit (Ex. 1006)

Internet Explorer 5 Resource Kit (“IE5 Resource Kit”) (Ex. 1006) is a book that “provides comprehensive information about planning, customizing, installing, and supporting the latest version of Internet Explorer.” Ex. 1006 at xi. The operation and features of IE5 Resource Kit are explained in greater detail in Ex.

1003 at ¶¶ 204-216, and below with respect to the claims.

IE5 Resource Kit was published in April 4, 1999, by Microsoft Press, and is therefore prior art to the ’643 patent under 35 U.S.C. § 102(b). See Ex. 1038

(copyright registration certificate showing publication date); see also Ex. 1006 at 4

(title page showing 1999 copyright year); Ex. 1003 at ¶ 149. Additional evidence of the publication of IE5Resource Kit includes its copyright registration—a record submitted to and completed by the United States Copyright Office that is also signed by a representative of the publisher of IE5 Resource Kit. Ex. 1038 at 1-2.

Its copyright registration states that IE5 Resource Kit has a publication date of

17


November 9, 1999. See id.

; CA, Inc.

, 780 F.Supp.2d at 307-308. Prior to the effective filing date of the ’643 patent, interested members of the public could purchase IE5 Resource Kit from bookstores and directly from Microsoft, and could access the book via mspress.microsoft.com/reslink. See, e.g., Ex. 1006 at iii, 650-

52. And they would have been able to find IE5 Resource Kit with a reasonable search. For example, Microsoft Press advertised IE5 Resource Kit before the effective filing date of the ’643 patent. See, e.g., Ex. 1019 at 2, 5 (Feb. 17, 2000 press release announcing the current availability of Microsoft Windows 2000

Server Resource Kit, a set of books different from Windows Resource Kit that included IE5 Resource Kit; see also Ex . 1039 at 2 (IE5 Resource Kit included).

That persons of skill in the art could discover and obtain IE5 Resource Kit prior to the effective filing date of the ’643 patent is confirmed by the actual receipt of the book by members of the public. See, e.g., Ex. 1039 at 2 (IE5 Resource Kit included), 4 (March 6, 2000 review).

3.

Overview of Elgamal (Ex. 1007)

U.S. Patent No. 5,657,390 (“Elgamal”) (Ex. 1007) was filed August 25,

1995 and issued August 12, 1997, Ex. 1007 at face, and is therefore prior art to the under 35 U.S.C. § 102(b). Elgamal is titled “Secure Socket Layer Application

Program Apparatus and Method.” Id . Among other things, Elgamal describes the

“Secure Sockets Layer (SSL)” security protocol, e.g

., Ex. 1007 at 5:15-29,

18

Petition in IPR2015-01009 including SSL version 3, see, e.g

., id . at 18:66-67.

B.

Windows Resource Kit (Ex. 1005) Anticipates Claims 1-9, 12, 14,

17-24, 27, and 29

1.

Independent Claims 1 and 17 Are Anticipated

Claims 1 and 17 are defined using the same operative limitations. See

Ex. 1001 at 55:46-67, 57:12-37. Claim 1 is cast in the form of a method for establishing an encrypted communication link between two devices; claim 17 is cast in the form of a first device configured to execute the steps of the method defined in claim 1. In this analysis, the method steps of claim 1 are first addressed, followed by the corresponding system elements of claim 17. a) Claim 1 Preamble

The preamble of claim 1 specifies “ a method for establishing an encrypted communication link between a first device and a second device over a communication network .” Windows Resource Kit discloses that a computer running Windows 2000 (a “first device”) can establish an encrypted connection with a remote computer (a “second device”), using a mechanism called IP Security

(IPSec). See, e.g., Ex. 1005 at 25, 53, 529, 583-587, 1018-1027. In one configuration, Windows 2000 IPSec protects data by encrypting data prior to transmission (“encrypted communication link”) on the network such as an intranet or the Internet (“a communication network”). See, e.g.

, Ex. 1005 at 1018; Ex.

1005 at 1021; Ex. 1003 at ¶¶ 195-203. Windows Resource Kit thus discloses the

19

Petition in IPR2015-01009 preamble specified in claim 1 . b) “enabl[e/ing]. . . a secure communication mode without a user entering any cryptographic information for establishing the . . . mode . . .”

Both claims 1 and 17 require that a “ secure communication mode ” is enabled “ without a user entering any cryptographic information for establishing the secure communication mode .” Windows Resource Kit discloses that IPSec can be enabled on a Windows 2000 computer using security policies. Ex. 1005 at

1020. Windows Resource Kit discusses two ways in which local security policies can be enabled: (1) choosing one of three predefined local IP Security policies to enable (Ex. 1005 at 1024-1026); and (2) creating custom local IP Security policies using the IP Security Policy wizard ( id.

at 1026-1027). Windows Resource Kit depicts the interface that allows selection and activation of IPSec policies:

Ex. 1005 at 1025; Ex. 1003 at ¶¶ 185-194.

20


By selecting from a dropdown user interface element, a user can enable one of three security policies: 1) a “Low” security mode that establishes secure communications if security is requested by a remote computer; 2) a “Moderate” security mode that does not require secure communications but requests that security be used for each connection; and 3) a “High” security mode that requires that all communications be secured. Ex. 1005 at 1024-1025; Ex. 1003 at ¶¶ 189-

190. At least the second and third configurations are a secure communication mode because they request or require protections that would restrict access to communications. Ex. 1003 at ¶¶ 189-190. Indeed, in the third configuration, all communications will be protected. Id. A user is not required to enter any cryptographic information in order to enable these policies, but can simply choose the desired policy in the IP Security dialog window and click the “OK” button. Ex.

1005 at 1024-1025; Ex. 1003 at ¶ 193. Selecting and activating one of the three predefined security policies meets this limitation as specified in claims 1 and 17 .

Similarly, Windows Resource Kit explains a user can create custom security policies. Ex. 1005 at 1026-1027. A person of ordinary skill in the art would have understood that this functionality would have allowed the user to create security policies similar to, or combining, the aspects of the Low, Moderate, and High security policies, thus controlling the scenarios in which encryption would be required. Ex. 1003 at ¶¶ 191-193. Thus, Windows Resource Kit also teaches

21

Petition in IPR2015-01009 custom security policies that are secure communication modes. Id.

In creating a custom security policy, a user can choose the policy name and description, and whether the custom policy should be the default. See, e.g., Ex. 1005 at 1027.

These options are not cryptographic information. Ex. 1003 at ¶ 193. A user also has the option of choosing the authentication method used with the policy, but does not need to. Ex. 1005 at 1027 (“Use this option to select the method of authentication for the default rule, if chosen ”) (emphasis added). After creating a custom policy, a user can then select and activate the policy using the IP Security configuration utility described above. See, e.g., Ex. 1005 at 1025; Ex. 1003 at ¶¶

191-193. Creating, and then selecting and activating a custom security policy also meets this claim limitation as specified in claims 1 and 17 . c) “establishing, based on a determination that the secure communication mode has been enabled, the encrypted communication link between the first device and the second device over the communication network, the establishing including”

When a Windows 2000 computer attempts to connect to a remote host (for example, when an application such as a web browser requests a connection to remote web site), Windows 2000 will first determine whether there is an active security policy enabled on the computer, and will then apply that policy in establishing a communication link. Ex. 1005 at 1020-21. As explained regarding the “ enabling ” claim element, see § IV.B.1.b), above, Windows Resource Kit

22

Petition in IPR2015-01009 teaches configurations (such as the Secure Server security policy) in which the applied security policy will result in communications being encrypted prior to transmission over the network (“ encrypted communication link ”). Ex. 1005 at

1021-27; Ex. 1003 at ¶¶ 185-194. Windows Resource Kit provides an overview of the process by which an encrypted communication link using IPSec is established, explaining that: (1) Computer A creates packets to send to computer B across the network; (2) IPSec checks the security policy on Computer A to determine the active policy on computer A (“ a determination that the secure communication mode has been enabled ”); (3) based on the security policy, Computer A begins security negotiations with Computer B, and the computers exchange public keys and create a shared, secret key; (4) Computer A signs and encrypts outgoing packets and sends them to Computer B; (5) routers and servers pass packets from

Computer A to Computer B; (6) Computer B checks the received packets for integrity and decrypts them, then passes them to the receiving application. Ex.

1005 at 1021-1022 (referencing Figure 22.19); Ex. 1003 at ¶ 195-203; see also id.

at ¶¶ 128-146. Thus, Windows Resource Kit shows establishing an encrypted communication link between two computers based on a determination that a secure communication mode has been enabled, as required by claims 1 and 17 . d) “construct[ing] a domain name based on an identifier associated with the second device”

Both claims 1 and 17 require, as part of establishing an encrypted

23

Petition in IPR2015-01009 communication link between the first and second devices, “ construct[ing] a domain named based on an identifier associated with the second device.

”

Windows Resource Kit explains that IPSec is one of the TCP/IP features offered by Windows 2000. Ex. 1005 at 951-952. Windows Resource Kit further discloses that establishing a TCP/IP connection requires using an IP address, whereas users and applications generally use names to identify computers. Ex. 1005 at 964; see

Ex. 1003 at ¶¶ 102-114. In the Windows Resource Kit scheme, Domain Name

System (DNS) resolution is the default method for converting computer names to computer IP addresses. Ex. 1005 at 965. Windows Resource Kit teaches that if an application running on a Windows 2000 computer wishes to communicate with another computer, a local DNS resolver component on the first computer will receive a DNS request from the application, send a query containing domain names to DNS servers, and receive responses from those DNS servers containing the IP addresses corresponding to the queried domain name. Ex. 1005 at 964-965.

Windows Resource Kit teaches that an application can send the local DNS resolver the “host name” of another computer, which can be a portion of the fully qualified domain name for that computer. Ex. 1005 at 967. For example, if the fully qualified domain name of a computer is client1.reskit.com

, the host name for this computer would be client1 . Id.

; Ex. 1003 at ¶¶ 160-165.

This host name is “ an identifier associated with a second device ” because it is a name that is used to

24

Petition in IPR2015-01009 identify the second device. Windows Resource Kit discloses at least four scenarios in which the Windows 2000 DNS resolver will construct a domain name using the hostname identifier. Ex. 1005 at 973-977. Windows Resource Kit illustrates the construction of the domain name in these scenarios using flowcharts. See Ex. 1005 at 964 (Fig. 22.2), 974 (Fig. 22.5), 975 (Fig. 22.6); Ex. 1003 at ¶¶ 164-171.

In the first scenario (described as the default), the “Append primary and connection specific DNS suffixes” option is selected in the “DNS” tab of the

“Advanced TCP/IP Settings” menu. In this scenario, the resolver constructs a domain name by appending a pre-configured primary DNS suffix to the host name.

Ex. 1005 at 976. For example, if the host name of the remote computer is client1 and the primary DNS suffix that has been set for the Windows 2000 computer is dom1.acquired01-int.com

the resolver will construct the domain name client1.dom1.acquired01-int.com

, and send a query containing that domain name to a DNS server. Ex. 1005 at 976. Ex. 1003 at ¶ 165.

If that query fails to return an IP address, Windows Resource Kit discloses a second scenario where the “DNS suffix for this connection” field in the “Advanced

TCP/IP Settings” menu contains an entry. As in the first scenario, the resolver constructs a domain name by appending this connection-specific suffix to the host name. Id.

For example, if the host name is client1 and the connection specific suffix is acquired01-ext.com

, then the resolver will construct the domain name

25

Petition in IPR2015-01009 client1.acquired01-ext.com

and query one or more DNS servers using this domain name. Id ; Ex. 1003 at ¶ 166.

A third scenario described by Windows Resource Kit for constructing a domain name is “name devolution.” Ex. 1005 at 977. In this scenario, the

“Append parent suffixes of the primary DNS suffix” option is selected in the

“Advanced TCP/IP Settings” menu. Id. When the resolver receives a request to resolve a host name (e.g., client1) it will create a domain name by appending the primary DNS suffix as discussed above in the first scenario, and will send a query with that domain name to one or more DNS servers. Id.

The resolver will then

“devolve” that domain name by iteratively stripping off the leftmost label of the primary DNS suffix to construct additional domain names until only two labels remain. Ex. 1005 at 977. For example, if the host name queried was client1 and the primary DNS suffix was dom1.acquired01-int.com

, the resolver would first query client1.dom1.acquired01-int.com

and then strip off the leftmost label

( dom1 ) to construct yet another domain name client1.acquired01-int.com

, for which the resolver would also send a query. Id.

; Ex. 1003 at ¶ 167.

The fourth scenario described by Windows Resource Kit relates to the use of a “domain suffix search list.” Ex. 1005 at 977. In this scenario, when the resolver receives a host name, it will construct domain names by adding pre-configured domain search suffixes (in order) to the host name and submitting queries to one or

26

Petition in IPR2015-01009 more DNS servers. Id. For example, if the host name is coffee and the DNS suffixes are those shown in Figure 22.7, the resolver will construct the following domain names based on the host name: coffee.com

, coffee.reskit.com

, coffee.redmond.reskit.com

. Id.

; Ex. 1003 at ¶¶ 168-170.

Each of these scenarios described by Windows Resource Kit discloses this limitation as specified in claims 1 and 17 . e) “send[ing] a query using the domain name”

Both claims 1 and 17 require, as part of establishing an encrypted communication link between the first and second devices, “ sending a query using the domain name ” that was constructed as part of the previous claim element.

Windows Resource Kit teaches that the DNS resolver component in Windows

2000 can resolve domain names by sending queries containing a domain name to one or more DNS servers. Ex. 1005 at 964, 967. As explained above in

§ IV.B.1.d), as part of the name resolution process, the local DNS resolver can construct a domain name based on an identifier associated with a second computer.

Once the Windows 2000 DNS resolver has constructed the domain name, it will send a query containing this domain name to one or more DNS servers for resolution. See generally Ex. 1005 at 964-983; see Ex. 1005 at 964 (Fig. 22.2),

974 (Fig. 22.5), 975 (Fig. 22.6); see also id.

at 978-982 (Figs. 22.8, 22.9, 22.10);

Ex. 1003 at ¶¶ 162-171. Thus, Windows Resource Kit discloses this limitation as

27

Petition in IPR2015-01009 specified in claims 1 and 17 . f) “receiv[e/ing], in response to the query, at least one network address associated with the domain name”

C laims 1 and 17 both require that at least one network address associated with the domain name queried is received in response to the query. As explained above at § IV.B.1.e), Windows Resource Kit teaches a configuration in which the local DNS resolver on the first device sends a query containing a constructed domain name to one or more DNS servers. Windows Resource Kit further discloses that in that configuration the local DNS resolver on the first device receives a response containing one or more IP addresses from the DNS server queried. Ex. 1005 at 979-982; Ex. 1003 at ¶¶ 172-173. Windows Resource Kit shows that queries are submitted to DNS servers and that responses from those

DNS servers are returned. Id. (Figs. 22.8, 22.9, and 22.10) .

Windows Resource

Kit teaches that multiple IP addresses can be received from a DNS server in response to a domain name query by describing a “subnet prioritization” feature that “prevents the resolver from choosing the first IP addresses returned in the

DNS query.” Ex. 1005 at 986; Ex. 1003 at ¶¶ 174-175. Accordingly, Windows

Resource Kit discloses this element of claims 1 and 17 . g) “initiat[e/ing] establishment of the encrypted communication link between the first device and the second device over the communication network using the at least one network address and encrypted

28

Petition in IPR2015-01009 communication link resources received from a server that is separate from the first device”

Windows Resource Kit further discloses that the encrypted communication link is initiated using, inter alia , the IP address (or one of the IP addresses if multiple are received) received from the DNS query (as described above in §

IV.B.1.f)) and the public key of the remote host. Windows Resource Kit discloses that as part of establishing a connection using IPSec the application on the

Windows 2000 computer generates outbound packets. See, e.g

., Ex. 1005 at 1021;

Ex. 1003 at ¶ 196; see also id.

at ¶¶ 133-139. Windows Resource Kit explains that those packets contain the IP address both of the sending computer and of the remote host. See Ex. 1005 at 1006. Thus, as part of initiating an encrypted IPSec communication link, the first computer will use at least one of the network addresses received from the DNS query.

Windows Resource Kit further explains that, in order to set up an encrypted channel between computers using IPSec, the computers must engage in security negotiations, which involves exchanging public keys and using these exchanged keys to create a shared key for the communication session. Ex. 1005 at 1021-22;

Ex. 1003 at ¶¶ 198-201; see also id.

at ¶¶ 123-126, 140-142. Thus the first computer receives a public key from the remote host (which in some configurations is a server, see, e.g

., Ex. 1005 at 1025). Windows Resource Kit teaches that once this shared key has been generated, it is used to authenticate the

29

Petition in IPR2015-01009 session and secure data exchange can begin between the two computers. Ex. 1005 at 2012; Ex. 1003 at ¶ 202. Windows Resource Kit further discloses that, as part of the security negotiation process, several things are determined, including an authentication method, a hashing method, a tunneling method, and an encryption method. Ex. 1005 at 1021; see Ex. 1003 at ¶¶ 128-142. The public key received from the remote computer is an encrypted communication link resource received from a server that is separate from the computer running Windows 2000, as is each piece of information received from the remote host as part of the negotiation process. See Ex. 1003 at ¶¶ 198-201. Accordingly, Windows Resource Kit discloses this limitation as specified in claims 1 and 17 . h) Additional System Elements of Claim 17

Claim 17 specifies a first device comprising (1) a “communications component” that communicates over a network; (2) a “memory” storing computer program instructions; and (3) at least one “processor” configured to execute these instructions to perform the operations explained above. As one of ordinary skill in the art would have understood, the Windows 2000 operating system is a set of computer instructions that is executed by a processor in a computer that has memory and a network adapter (a communications component). See Ex. 1005 at

1022; Ex. 1003 at ¶¶ 156-157. Windows Resource Kit shows hardware requirements for computers on which the Windows 2000 operating system will be

30

Petition in IPR2015-01009 installed, including the speed of the processor, the amount of memory (both RAM and hard drive space), and a network adapter. Ex. 1005 at 107; Ex. 1003 at ¶ 157.

As Windows Resource Kit explains, the computer instructions that make up

Windows 2000 are stored in the computer’s memory. See, e.g.

, Ex. 1005 at 105;

Ex. 1003 at ¶¶ 157-158. Windows Resource Kit thus shows a computer (“ first device ”) comprising “ a memory storing computer instructions ” and “ at least one processor ” as specified in the preamble of claim 1 . Further, Windows Resource

Kit explains that this computer (“ first device ”) may contain one or more network adapters, modems, or other telecommunications devices (each a “ communications component ”). Ex. 1005 at 84. These communication components allow the first device to communicate with another device (“ second device ”) over a communications network, such as a local area connection or an internet connection. Ex. 1005 at 882-883; see Ex. 1003 at ¶ 157. Windows Resource Kit therefore also shows a “ first device configured to communicate with a second device over a communication network ” as specified in the preamble of claim 1 .

2.

Claims 2, 4, and 18 Are Anticipated

Windows Resource Kit anticipates claim 1 and 17 from which claims 2 and

18 depend, respectively. See § IV.B.1, above . Claim 4 depends on claim 2.

Claim 2 further recites “ wherein enabling the secure communication mode includes receiving a command entered into the first device by the user, and the

31

Petition in IPR2015-01009 command specifies the secure communication mode.

” Claim 4 further recites

“ wherein receiving the command includes: displaying, at the first device, a user interface including a user interface element for enabling the secure communication mode; and receiving the command from the user via the user interface element .”

Claim 18 combines the elements of claims 2 and 4, specifying the “ first device of claim 17, further comprising : a display device; wherein the at least one processor further executes the instructions to: display, on the display device, a user interface including a user interface element for enabling the secure communication mode; receive a command from the user via the user interface element; and enable the secure communication mode in response to receiving the command .” a) Claim 2 “wherein enabling the secure communication mode includes receiving a command entered into the first device by the user, and the command specifies the secure communication mode”

As explained above in § IV.B.1 in connection with claims 1 and 17,

Windows Resource Kit allows a user to enable IP Security policies (a secure communication mode) by selecting the desired policy from a drop-down list and activating the “OK” button (“ a command entered into the first device by the user ”).

Ex. 1005 at 1024-27. Choosing the policy “ specifies ” the secure communication mode by identifying the selected policy (“ secure communication mode ”) amongst the other policies. For example, if the High security policy is chosen, the user’s selection of that policy identifies the policy as the one that is enabled. See Ex.

32


1003 at ¶¶ 188-190. In response to selecting a security policy and activating it, the computer running Windows 2000 enables that policy, using it for subsequent communication attempts). Ex. 1005 at 1021-1022; Ex. 1003 at ¶ 190. b) Claim 4 “displaying, at the first device, a user interface including a user interface element for enabling the secure communication mode; and receiving the command from the user via the user interface element.”

Windows Resource Kit discloses that Windows 2000 is an operating system that provides a user interface. See, e.g., Ex. 1005 at 7 (“Windows 2000 has an improved user interface”), 353. Windows Resource Kit further discloses that the user interface in Windows 2000 provides multiple user interface elements, including the IP Security dialog window. Ex. 1005 at 1025.

Id . Windows Resource Kit discloses that IPSec can be enabled on a Windows

2000 computer through the selection of one of the three predefined local IP

33


Security policies presented in this IP Security dialog window. Ex. 1005 at 1024-

1026; Ex. 1003 at ¶¶ 188-190. Another user interface element disclosed by

Windows Resource Kit is the IP Security Policy Wizard, which is part of the IP

Security Policy Management Console. Ex. 1005 at 1026-1027. This wizard allows a user to create a local security policy that will be used (enabled) by the Windows

2000 operating system. Id.

; Ex. 1003 at ¶¶ 191-193. Windows Resource Kit’s disclosure of these user interface displays for configuring IP security meets

“ displaying, at the first device, a user interface including a user interface element for enabling the secure communication mode.

”

When the user enters a command using either the IP Security dialog (i.e., picking one of the three pre-defined security policies) or the IP Security Policy wizard (i.e., creating a custom local security policy), the computer running the

Windows 2000 receives the command via its user interface. Ex. 1005 at 1024-

1027 (“ receiving the command from the user via the user interface element ”). c) Claim 18

Claim 18 specifies that the device of claim 17 also includes a “ display device .” As shown above regarding claim 4, see § IV.B.2.b), the computer running

Windows 2000 displays the interface used to configure IP Security. A person of ordinary skill in the art would have understood that displaying an interface required inclusion of a display device. Ex. 1003 at ¶ 157. Moreover, Windows

34


Resource Kit discloses that a user can connect up to 10 monitors (each a “ display device ”) to a computer running Windows 2000. Ex. 1005 at 453.

Claim 18 also specifies “ wherein the at least one processor further executes the instructions to ” and then recites various functionalities. Windows Resource

Kit shows that the Windows 2000 operating system is a set of computer instructions that is executed by a processor in a computer. Ex. 1005 at 107.

Claim 18 specifies “ wherein the at least one processor further executes the instructions to: display, on the display device, a user interface including a user interface element for enabling the secure communication mode.

” Windows

Resource Kit discloses this limitation for the same reasons as explained with respect to the “ displaying, at the first device, a user interface including a user interface element for enabling the secure communication mode ” limitation of claim

4. See § IV.B.2.b), above; Ex. 1005 at 1005 at 1025; Ex. 1003 at ¶ 157, 188.

Claim 18 also specifies “ wherein the at least one processor further executes the instructions to: … receive a command from the user via the user interface element.

” Windows Resource Kit discloses this limitation for the same reasons as explained with respect to the “ displaying, at the first device, a user interface including a user interface element for enabling the secure communication mode ” limitation of claim 4. See § IV.B.2.b) above; Ex. 1005 at 1005 at 1025.

Claim 18 also specifies “ wherein the at least one processor further executes

35

Petition in IPR2015-01009 the instructions to: … enable the secure communication mode in response to receiving the command.

” Windows Resource Kit discloses this limitation for the same reasons as explained with respect to the “ wherein enabling the secure communication mode includes receiving a command entered into the first device by the user, and the command specifies the secure communication mode ” limitation of claim 2. See § IV.B.2.a) above; Ex. 1005 at 1021-1022; Ex. 1003 at ¶ 190.

3.

Claims 3 and 19 Are Anticipated

Windows Resource Kit anticipates claims 2 and 18, from which claims 3 and

19 depend, respectively. See § IV.B.2, above . Claims 3 and 19 require that the command received from the user “ defines a setup parameter associated with the secure communication mode .” As described above in § IV.B.2 in connection with claims 2 and 18, Windows Resource Kit discloses that a user can enter a command to enable one of three pre-defined security policies, or to create a custom local security policy. Ex. 1003 at ¶¶ 185-194. In both of these scenarios, the command received from the user defines a setup parameter that is associated with the secure communication mode. Ex. 1005 at 1024-25. When the user chooses between one of three pre-defined policies, these policies are setup parameters, as they define which (none, some, or all) connections will be secured. Ex. 1005 at 2024-25.

When the command from the user creates and enables a custom local security policy, the command specifies multiple setup parameters, such as the default rule,

36

Petition in IPR2015-01009 including the application of the default rule and, optionally, the authentication method for this rule. Ex. 1005 at 1027; Ex. 1003 at ¶ 193.

4.

Claims 5, 6, 20, and 21 Are Anticipated


20 depend, respectively. See § IV.B.1, above . Claims 5 and 20 additionally recite that “ the user interface comprises an application stored” in the memory of the first device. Claims 6 and 21 depend from claims 5 and 20 (respectively), and additionally recite that the “ application comprises a web browser .” As explained above in §§ IV.B.1.h) and IV.B.2, Windows Resource Kit teaches that the

Windows 2000 operating system provides a user interface and is stored on a computer. Windows Resource Kit discloses that Windows 2000 comes with

Internet Explorer 5 “built in.” Ex. 1005 at 11. Internet Explorer 5 is therefore stored on the computer and is part of the Windows 2000 user interface. Internet

Explorer 5 is an application that is a web browser. Ex. 1005 at 12. Thus, Windows

Resource Kit anticipates claims 5, 6, 20, and 21 .

5.



22 depend, respectively. See § IV.B.1, above. Claims 7 and 22 additionally recite

“ wherein sending the query using the domain name includes sending, to a secure domain name service (SDNS), a query for a network address associated with the

37

Petition in IPR2015-01009 domain name .” An SDNS is a service that provides a secure computer network address for a requested secure domain name, such as a network address for a secure computer or service, or an address in a secure computer network.

See §§ III.D.4-III.D.5, above; Ex. 1003 at ¶¶ 67-69.

As explained above in § IV.B.1 in connection with claims 1 and 17,

Windows Resource Kit discloses that, in order to initiate communication with another computer, the DNS resolver component in Windows 2000 will construct a domain name and submit a query containing that domain name to a DNS server.

Windows Resource Kit explains that the computers with which communication can be initiated include ones that that request that communications be encrypted ( see, e.g.

, Ex. 1024), and ones that use authentication ( see, e.g

., Ex. 1005 at 1027

(discussing authentication methods)). These computers are thus secure computers, making their addresses secure network addresses. See Ex. 1003 at ¶¶ 67-69. The

DNS servers of Windows Resource Kit are therefore SDNS’s because they can resolve these addresses.

Windows Resource Kit also discloses this limitation even under the narrower construction for “ secure domain name ” that Patent Owner has proposed in related proceedings (i.e., a “non-standard domain name that corresponds to a secure computer network address and cannot be resolved by a conventional domain name service (DNS).”) See IPR2014-00481, Paper 20 at 15-17 (Jan. 5,

38


2015). Windows Resource Kit discloses an example (with reference to Figure

22.12) of a computer running Windows 2000 with multiple network interfaces

(multihomed) that uses a name server on a corporate intranet to resolve intranet names that are queried using the adapter connected to the local network, while also using a name server on the Internet to resolve Internet names that are queried using the adapter connected to the public network. Ex. 1005 at 989-990.

Id . at 990. The name server running on the intranet is a secure domain name service even under Patent Owner's narrow construction because this name server is inaccessible outside of the intranet and cannot resolve conventional DNS requests.

Id. Windows Resource Kit thus discloses this limitation as specified in claims 7 and 22 .

6.



23 depend, respectively. See § IV.B.5, above. Claims 8 and 23 include the

39

Petition in IPR2015-01009 additional limitation of receiving a network address from the SDNS in response to the query sent. As explained above in § IV.B.1.e), Windows Resource Kit teaches that the Windows 2000 DNS resolver can send a query containing a constructed domain name to one or more DNS servers. And, as explained above in connection with claims 7 and 22, Windows Resource Kit discloses that a DNS server to which the Windows 2000 resolver may submit domain names is a secure domain name server that resolves domain names for clients on an intranet. See § IV.B.5, above.

Windows Resource Kit further discloses that the Windows 2000 DNS resolver can receive a response containing one or more IP addresses from the DNS server queried. For example, Windows Resource Kit provides a flowchart (Figs. 22.8,

22.9, and 22.10) that shows how queries are submitted to DNS servers and how responses from those DNS servers are returned. Ex. 1005 at 979-981. Windows

Resource Kit thus discloses this limitation as specified in claims 8 and 23 .

7.



24 depend, respectively. See § IV.B.6, above. Claims 9 and 24 include the additional limitation of receiving a “ list of network addresses associated with the domain name ” queried. As explained above in § IV.B.1.e), Windows Resource Kit teaches that the Windows 2000 DNS resolver may query a secure domain name server with a constructed domain name. See Ex. 1005 at 1027; Ex. 1003 at ¶¶ 67-

40


69. Windows Resource Kit further discloses that multiple IP addresses (“ a list of

IP addresses ”) can be received in response to this domain name query, and describes a feature termed “subnet prioritization” that “prevents the resolver from choosing the first IP addresses returned in the DNS query.” Ex. 1005 at 986; Ex.

1003 at ¶¶ 174-175. Windows Resource Kit further explains that if one or more IP addresses are returned from a DNS server for a queried domain name (a “positive response”), the DNS “stops querying for the name, adds the response to the cache and returns the response to the client.” Ex. 1005 at 982. Windows Resource Kit thus discloses this limitation as specified in claims 9 and 24 .

8.


Windows Resource Kit anticipates claims 1 and 17, from which claims 12 and 27 depend, respectively. See § IV.B.1, above. Claims 12 and 27 add the additional limitations that the “ identifier ” associated with the second computer

“ includes a non-secure domain name ” and that “ construct[ing] the domain name includes replacing the non-secure domain name with a secure domain name .” As explained in detail above in § IV.B.1.d), Windows Resource Kit discloses various methods by which the Windows 2000 resolver will construct domain names based on an identifier. Ex. 1003 at ¶¶ 162-X. As Windows Resource Kit explains, the

“Append primary and connection specific DNS suffixes” option is selected by default in the “DNS” tab of the “Advanced TCP/IP Settings” menu. Ex. 1005 at

41


976; Ex. 1003 at ¶ 165. In this scenario, if a host name (e.g., client1) is provided, the resolver will append the primary DNS suffix that has been configured for the

Windows 2000 computer to the host name. Ex. 1005 at 976; Ex. 1003 at ¶ 165.

Together, the client name and the DNS suffix make up a fully qualified domain name. Ex. 1005 at 972. For example, if the host name of the remote computer is client1 and the primary DNS suffix that has been set for the Windows 2000 computer is dom1.acquired01-int.com, the resolver will send a query containing that domain name to a DNS server. Ex. 1005 at 976; Ex. 1003 at ¶ 165. This domain name is an “ identifier associated with a second computer ,” and can be either a secure or non-secure domain name, depending on whether the primary

DNS suffix that has been set can be resolved conventionally or not (e.g., whether the fully qualified domain name can be resolved by a public DNS server). If this query fails to return an IP address, and the “DNS suffix for this connection” field in the “Advanced TCP/IP Settings” menu contains an entry, then the DNS resolver will replace the fully qualified domain name with another domain name that is constructed by appending the connection-specific suffix to the host name. Id.

For example, if the host name is client1 and the connection specific suffix is acquired01-ext.com

, then the resolver will construct the domain name client1.acquired01-ext.com

and query one or more DNS servers using this domain name. Id. This domain name can either be a secure or non-secure domain

42

Petition in IPR2015-01009 name depending on whether the fully qualified domain name can be resolved conventionally.

Windows Resource Kit also discloses an example (with reference to Figure

22.12) of a computer running Windows 2000 with multiple network interfaces

(multihomed) that uses a name server on a corporate intranet to resolve intranet names that are queried using the adapter connected to the local network, while also using a name server on the Internet to resolve Internet names that are queried using the adapter connected to the public network. Ex. 1005 at 989-990.

Id.

In this scenario, when the “Append these DNS suffixes (in order)” option is selected in the “DNS” tab of the “Advanced TCP/IP Settings” menu for the local adapter and one or more domain suffixes have been entered for this adapter, the resolver will construct domain names by adding these domain suffixes (in order) to the host name and submitting queries to the intranet DNS server. Id. For example, if the host name is coffee and the DNS suffixes are those shown in Figure 22.7, the

43

Petition in IPR2015-01009 resolver will construct the following domain names based on the host name: coffee.com

, coffee.reskit.com

, coffee.redmond.reskit.com

. Id.

; Ex. 1003 at ¶¶

168-170. The intranet DNS server will not resolve the non-secure (public) domain name coffee.com

, but will resolve the secure (private) domain name coffee.reskit.com

or coffee.redmond.reskit.com

. Windows Resource Kit thus discloses this limitation as specified in claims 12 and 27 .

9.


Windows Resource Kit anticipates claims 1 and 17, from which claims 14 and 29 depend, respectively. See § IV.B.1, above. Claims 14 and 29 add the limitation that “ the encrypted communication link comprises a virtual private network communication link over the communication network .” As explained above at IV.B.1.g), Windows Resource Kit discloses that IPSec can be used to create secure connections between computers via end-to-end encryption and data authentication. Ex. 1005 at 25, 53, 583-87, 890, 917-18, 1019-1027; Ex. 1003 at

¶¶ 128-146, 176-184. Windows Resource Kit thus discloses a “ virtual private network communication link ” between the Windows 2000 computer and the remote computer, at least because Windows Resource Kit discloses a transmission path between two devices that restricts access to data using encryption. Windows

Resource Kit thus discloses this limitation as specified in claims 14 and 29 .

44


C.

Windows Resource Kit (Ex. 1005) In View of IE5 Resource Kit

(Ex. 1006) and Elgamal (Ex. 1007) Renders Obvious Claims 1, 13,

15-17, 28, and 30-32

1.

Combining Windows Resource Kit and IE5 Resource Kit and Elgamal

As explained above in § IV.A.3, Windows Resource Kit alone —by way of its description of domain name resolution and IPsec encryption functionality in

Windows 2000—renders many claims of the ’643 patent invalid. As explained further below, Windows Resource Kit suggests but does not explicitly disclose elements specified in dependent claims 13, 15, 16, 28 and 30-32. A configuration of Internet Explorer 5 (IE5) running on Windows 2000 and which encrypts communications using the Secure Sockets Layer (SSL) protocol, however, is suggested by Windows Resource Kit in combination with IE5 Resource Kit or

Elgamal. Such configurations would meet the limitations of these dependent claims, rendering them obvious as described below in sections IV.C.3-IV.C.6.

It would have been obvious to combine the teachings of IE Resource Kit with those in Windows Resource Kit. Windows Resource Kit discusses including

IE5 ( see, e.g

., Ex. 1005 at 8) but does not explicitly describe the details of configuration and use of IE5. IE5 Resource Kit, however, describes those details and would have been recognized as being a detailed resource (on IE5 configuration and use) to the person of ordinary skill. A person of ordinary skill in the art would have been motivated to consider the additional technical guidance provided in IE5

45


Resource Kit in conjunction with the teachings about the Windows 2000 operating system provided in Windows Resource Kit. Windows 2000 actually included IE5 in its distributions, which shows that the references are directed to analogous fields of endeavor. E.g

., Ex. 1005 at 11. Moreover, a person of ordinary skill in the art would have understood that IE5, as described in IE5 Resource Kit, provided a number of new and useful features. Ex. 1006 at 3; see also id . at 3-29; Ex. 1003 at

¶ 267. It would have taken only routine effort to configure IE5 for use in Windows

2000 pursuant to the collective guidance provided by IE5 Resource Kit and

Windows Resource Kit. Implementing the combination could be accomplished by simply installing Windows 2000, which Windows Resource Kit describes in detail how to do. See, e.g

., Ex. 1006 at v-xxxii (table of contents showing chapters related to installation). IE5 Resource Kit also extensively describes installation of

IE5 in various Windows OS operating environments. See Ex. 1006 at v-x (table of contents); see also id . 163-583; Ex. 1003 at ¶ 267.

A person of ordinary skill also would have considered the identified teachings of Windows Resource Kit and IE5 Resource Kit in conjunction with those in Elgamal. Windows Resource Kit and IE5 Resource Kit both discuss the

Secure Sockets Layer (SSL) standard ( see, e.g

., Ex. 1005 at 593; Ex. 1006 at 99), but neither describes the functionality present in SSL that Petitioner recites in the claims. Elgamal provides a comprehensive description of the functionality,

46

Petition in IPR2015-01009 features and use of the SSL standard. A person of ordinary skill would have been motivated to consider Elgamal in conjunction with Windows Resource Kit and IE5

Resource Kit as Elgamal describes the SSL protocol that IE5 Resource Kit says is implemented in the IE5 software that Windows Resource Kit explains is included in Windows 2000. Ex. 1006 at 99; Ex. 1007 at 5:15-29, 18:66-67; Ex. 1005 at 11;

Ex. 1003 at ¶ 268. Moreover, a person of ordinary skill in the art would have understood that implementing secure web browser functionality using SSL in an operating system like Windows 2000 would have allowed users to access sensitive websites. See, e.g

., Ex. 1006 at 99; Ex. 1003 at¶ 268.

When considered together, the three references specifically suggest configuration of a computer running Internet Explorer 5 (as described by IE5

Resource Kit) that uses SSL (as described by Elgamal) to access secure web pages using the existing domain name and networking functionality within Windows

2000 (as described by Windows Resource Kit). See Ex. 1005 at 964; Ex. 1003 at

¶¶ 91-93, 161, 267. When so configured, this suggested system would meet every element of claims 13, 15, 16, 28 and 30-32, as explained below.

2.

Claims 1 and 17 Would Have Been Obvious over Windows

Resource Kit in View of IE5 Resource Kit and Elgamal

Because dependent claims 13, 15, 16, 28, 30-32 each depend on independent claims 1 or 17, Petitioner describes how an SSL implementation of a system suggested by the combination of Windows Resource Kit, IE5 Resource Kit, and

47


Elgamal would have rendered these independent claims obvious. Specifically, in the SSL configuration suggested by these references, the claimed “ encrypted communication link ” would be present as a result of use of SSL functionality. a) Claim 1 Preamble

The preamble of claim 1 specifies “ a method for establishing an encrypted communication link between a first device and a second device over a communication network .” Implementing IE5 Resource Kit in the Windows

Resource Kit scheme would have resulted in a scheme in which the Internet

Explorer browser executed on a computer in conjunction with the Windows 2000 operating system. Ex. 1003 at ¶ 267. In that configuration, IE5 Resource Kit suggests configuring a computer running Internet Explorer (“ first device ”) to establish an encrypted connection with a server (“ second device ”) via a Secure

Sockets Layer connection (“ encrypted communication link ”) between the web browser running on a Windows 2000 computer and a remote server. Ex. 1006 at

99. Windows Resource Kit in view of IE5 Resource Kit and Elgamal thus suggests

“ a method for establishing an encrypted communication link between a first device and a second device over a communication network ” as specified in claim 1 . b) “enabl[e/ing]. . . a secure communication mode without a user entering any cryptographic information for establishing the . . . mode . . .”

Both claims 1 and 17 require that a “ secure communication mode ” is

48

Petition in IPR2015-01009 enabled “ without a user entering any cryptographic information for establishing the secure communication mode .” Elgamal explains that, when using SSL on a browser ( e.g.

, Internet Explorer 5 running on Windows 2000), a user can “click” or

“select[]” a link in order to access a webpage. Ex. 1007 at 9:32-38. Elgamal further explains that clicking certain link will trigger a series of processes that will ultimately establish an encrypted connection to a secure server. See, e.g., id . at

9:32-41. This process is initiated without a user entering in any cryptographic information. See id.

; Ex. 1003 at ¶ 221-223. Thus, in the SSL-configuration of an implementation of IE5 running on Windows 2000 suggested by the combined teachings of Windows Resource Kit in view of IE5 Resource Kit, the “ secure communication mode” established during SSL sessions as taught by Elgamal would be enabled “ without a user entering any cryptographic information for establishing the … mode…” as specified in claims 1 and 17 . c) “establishing, based on a determination that the secure communication mode has been enabled, the encrypted communication link between the first device and the second device over the communication network, the establishing including”

As discussed in § IV.C.2.b) above regarding the “ enabling ” element,

Elgamal teaches that clicking or selecting certain links in a browser ( e.g.

, Internet

Explorer 5 running on Windows 2000) triggers a series of processes that ultimately establish an encrypted link. See Ex. 1007 at 9:32-41. As Elgamal explains,

49

Petition in IPR2015-01009 clicking or selecting those links causes the local computer to transfer information over the Internet from a server. Ex. 1007 at 9:28-41. As Elgamal explains,

“Before the transfer can occur, … the handshake protocol is negotiated, and encryption/decryption information is developed.” Id . at 9:38-41. These processes occur only in response to (“ based on a determination that ”) the user clicking or selecting the link. See Ex. 1007 at 9:28-41; Ex. 1003 at ¶ 221-223. Elgamal thus teaches this element, and accordingly, a system suggested by the combined teachings of Windows Resource Kit in view of IE5 Resource Kit and Elgamal would meet this element of claims 1 and 17 . d) “construct[ing] a domain name based on an identifier associated with the second device”

Windows Resource Kit teaches this claim element as explained at

§ IV.B.1.d). A system implemented pursuant to the combined teachings of

Windows Resource Kit, IE5 Resource Kit and Elgamal would likewise handle domain name resolution as described in Windows Resource Kit. See § IV.C.1. e) “send[ing] a query using the domain name”

Windows Resource Kit teaches this claim element as explained at

§ IV.B.1.e). A system implemented pursuant to the combined teachings of

Windows Resource Kit, IE5 Resource Kit and Elgamal would likewise handle domain name resolution as described in Windows Resource Kit. See § IV.C.1.

50

Petition in IPR2015-01009 f) “receiv[e/ing], in response to the query, at least one network address associated with the domain name”

Windows Resource Kit teaches this claim element as explained above in §

IV.B.1.f). A system implemented pursuant to the combined teachings of Windows

Resource Kit, IE5 Resource Kit and Elgamal would likewise handle domain name resolution as described in Windows Resource Kit. See § IV.C.1. g) “initiat[e/ing] establishment of the encrypted communication link between the first device and the second device over the communication network using the at least one network address and encrypted communication link resources received from a server that is separate from the first device”

As explained above in § IV.B.1.g), Windows Resource Kit explains that network functionality in a Windows 2000 computer inserts the IP address of both the sending computer and the remote host into IP packets. See Ex. 1005 at 1006.

A system suggested by the combination of Windows Resource Kit, IE5 Resource

Kit, and Elgamal would have the network functionality described in Windows

Resource Kit. See § IV.C.1. Thus, when Internet Explorer 5 with SSL functionality (as suggested by IE5 Resource Kit in view of Elgamal) communicates with a web server, the network address obtained from the DNS query will be used to establish the connection between the web browser and the web server and to send packets back and forth between the browser and server.

Elgamal explains that, to establish an encrypted communication link

51

Petition in IPR2015-01009 connection using Secure Sockets Layer (SSL), a handshake is performed between the client computer and the server computer. See, e.g

, Ex. 1007 at 9:38-41; see also id . at 6:57–9:31. Elgamal further explains that the handshake is used to select cryptographic algorithms, authenticate client and server, and generate shared secrets for use in encryption. Ex. 1007 at 6:57–9:31. Elgamal teaches that the client will receive various encrypted communication link resources from the server, including a server certificate and a server “hello” message that contains a connection identification, a server certificate, and cipher specifications. Id . These pieces of information received from the server are encrypted communication link resources that are used to initialize the encrypted communication link between the computer running Internet Explorer 5 and a web server via SSL. Accordingly,

Windows Resource Kit in view of IE5 Resource Kit and Elgamal suggest this limitation in claims 1 and 17 . h) Additional System Elements of Claim 17

Claim 17 specifies a first device comprising (1) a “communications component” that communicates over a network; (2) a “memory” storing computer program instructions; and (3) at least one “processor” configured to execute these instructions to perform the operations explained above. The system suggested by the combination of Windows Resource Kit and IE5 Resource Kit would comprise computer hardware as described by Windows 2000 Resource Kit. As one of

52

Petition in IPR2015-01009 ordinary skill in the art would have understood, the Windows 2000 operating system is a set of computer instructions that is executed by a processor in a computer that has memory and a network adapter (a communications component).

As Windows Resource Kit explains, the Internet Explorer functionality is built into the Windows 2000 operating system (i.e., the Internet Explorer 5 web browser is a set of computer instructions that is included with the operating system). Ex. 1005 at 456. Windows Resource Kit provides a table that shows the minimum and recommended requirements for computers on which the Windows 2000 operating system will be installed, including the speed of the processor, the amount of memory (both RAM and hard drive space), and a network adapter. Ex. 1005 at

107. As Windows Resource Kit explains, the computer instructions that make up the Windows 2000 operating system (which include the Internet Explorer 5 web browser) are stored in the memory of the computer. See, e.g.

, Ex. 1005 at 105.

Windows Resource Kit thus shows a computer (“ first device ”) comprising “ a memory storing computer instructions ” and “ at least one processor ” as specified in the preamble of claim 17 . Further, Windows Resource Kit explains that this computer (“ first device ”) may contain one or more network adapters, modems, or other telecommunications devices (a “ communications component ”). Ex. 1005 at

84. These components allow the first device to communicate with another device

(“ second device ”) over a communications network, such as a local area connection

53

Petition in IPR2015-01009 or an internet connection. Ex. 1005 at 882-883. Windows Resource Kit, IE5

Resource Kit and Elgamal therefore also suggest a “ first device configured to communicate with a second device over a communication network ” as specified in the preamble of claim 17 .

3.

Claims 13 and 28 Would Have Been Obvious

Windows Resource Kit in view of IE5 Resource Kit and Elgamal would have rendered obvious claims 1 and 17, from which claims 13 and 28 depend, respectively. See § IV.C.2, above. Claims 13 and 28 additionally specify

“ determin[e/ing], by the first device in response to enabling the secure communication mode, whether a secure communication software module should be downloaded and stored on the first device; access[e/ing], by the first device and based on a determination that the secure communication software module should be downloaded and stored on the first device, a network address for loading the secure communication software module; and stor[e/ing] the secure communication software module at the first device .” Windows Resource Kit does not explicitly teach systems which possess this feature, but when considered in conjunction with the teachings in IE5 Resource Kit and Elgamal, this would have been an obvious variation of such systems.

IE5 Resource Kit teaches that the CryptoAPI 2.0 allows for developers to integrate cryptography (encryption) into their applications, and that Cryptographic

54


Service Provider modules (" security software modules ") can be added that can interface with this API to provide security. Ex. 1006 at 101. Moreover, IE5

Resource Kit explains that Internet Explorer can automatically install components needed by a website when a user visits that website. Ex. 1006 at 367; Ex. 1003 at

¶¶ 209-210. As part of that automatic installation functionality, IE5 Resource Kit also explains that Internet Explorer includes functionality to determine whether a component has already been installed. Id . at 369 (discussing IsComponentInstalled function). A person of ordinary skill would consider the SSL/https functionality taught by IE5 Resource Kit to be such a component that, if not initially installed, could be automatically installed as needed. Ex. 1003 at ¶ 211. One of ordinary skill would have been familiar with the advantages of implementing functional capabilities of software applications in this manner. See, e.g., Ex. 1003 at ¶¶ 212-

214; U.S. Patent No. 5,960,204 (Ex. 1036) at 1:21-34 (installing software as needed saves time and system resources) 1:32-42 (automatically determining when needed software was to be installed was known to be desirable). Thus, it would have been obvious to the person of ordinary skill based on the guidance in IE5

Resource Kit and their general knowledge to configure the system suggested by the combined teachings of Windows Resource Kit, IE5 Resource Kit and Elgamal so that when a user enabled the secure mode taught by IE5 Resource Kit and navigated to a page that used SSL/https, Internet Explorer would in response to

55

Petition in IPR2015-01009 that navigation, determine whether the SSL/https component was already installed, and if it was not, install the components needed to support such functionality. Ex.

1003 at ¶ 215.

In one configuration, this installation would have entailed downloading the

SSL/https component from a network server and storing the component on the disk drive of the computer running Internet Explorer. Ex. 1003 at ¶ 216. IE5 Resource

Kit explains that the installation files can be located on a network share (“ network address ”). Ex. 1006 at 411. IE5 Resource Kit also explains that installation involves storing the components on a storage device, such as the hard drive of the computer running Internet Explorer. Ex. 1006 at 500 (discussing the “disk space needed on the user’s computer”); id . at 496 (discussing the folder for installing files). Thus, in one configuration, the installation would involve “ download[ing] and stor[ing] on the first device ” the SSL/https component of Internet Explorer.

Such a configuration, when IE5 navigated to a webpage that required SSL, would meet “ determining, by the first device in response to enabling the secure communication mode, whether a secure communication software module should be downloaded and stored on the first device.

” Moreover, the subsequent installation of the SSL/https component of Internet Explorer in response to this determination would meet “ accessing, by the first device and based on a determination that the secure communication software module should be downloaded and stored on the

56

Petition in IPR2015-01009 first device, a network address for loading the secure communication software module; and storing the secure communication software module at the first device.

” Windows Resource Kit in combination with IE5 Resource Kit and

Elgamal therefore renders claims 13 and 28 obvious.

4.


Windows Resource Kit in view of IE5 Resource Kit and Elgamal would have rendered obvious claims 1 and 17, from which claims 15 and 31 depend, respectively. See § IV.C.2, above. Claims 15 and 31 require the additional limitation of displaying “ a visible indication on a display of the first device that the encrypted communication link is established .” Windows Resource Kit does not explicitly describe this feature, but a system suggested by a combination of it with

IE5 Resource Kit and Elgamal would have rendered this obvious. Specifically,

IE5 Resource Kit teaches that Internet Explorer 5 will display a lock icon when the browser has established a connection to a secure website – for example, when communicating with a website using SSL. Ex. 1006 at 152. This lock icon is a visible indication that appears on the display of the computer running Windows

2000 and indicates that an encrypted communication link has been established.

Windows Resource Kit in combination with IE5 Resource Kit and Elgamal therefore renders claims 15 and 31 obvious.

5.


57


Windows Resource Kit in view of IE5 Resource Kit and Elgamal would have rendered obvious claims 1 and 17, from which claims 16 and 32 depend, respectively. See § IV.C.2, above. Claims 16 adds the limitations “ wherein the enablement of the secure communication mode triggers establishing of the encrypted communication link ”, while claim 32 adds the limitation “ wherein the at least one processor executes the instructions to trigger the establishment of the encrypted communication link upon enablement of the secure communication mode .” Windows Resource Kit does not explicitly describe these features, but a system suggested by the combination of it with IE5 Resource Kit and Elgamal would have rendered these elements obvious. As explained at IV.C.2.b), IE5

Resource Kit teaches that a secure mode is enabled by Internet Explorer 5 when a user activates one or more security protocols (e.g., the SSL protocol) for the browser and instructs the browser to navigate to a secure web address (e.g., by clicking a link that contains “https://” or typing in a web address that contains

“https://”). One of ordinary skill in the art would have understood that, when the

Internet Explorer 5 browser is instructed to navigate to a secure web address, this instruction triggers the Internet Explorer 5 browser to establish a secure, encrypted connection to the server at this web address. Ex. 1003 at ¶¶ 207-208. Windows

Resource Kit in combination with IE5 Resource Kit and Elgamal therefore renders claims 16 and 32 obvious.

58


6.

Claim 30 Would Have Been Obvious

Windows Resource Kit in view of IE5 Resource Kit and Elgamal renders obvious claim 17, from which claim 30 depends. See § IV.C.2, above. Claim 30 adds the additional limitation “ wherein the encrypted communication link is one encrypted communication link in a hierarchy of a plurality of encrypted communication links established on the electronic network .” Windows Resource

Kit does not explicitly disclose this element, but a system suggested by the combination of it with IE5 Resource Kit and Elgamal would have rendered it obvious. IE5 Resource Kit explains that, in addition to standard encrypted SSL connections, the Internet Explorer 5 web browser can form encrypted connections using Server Gated Cryptography (SGC), which provides “stronger encryption for communication between clients and servers.” Ex. 1006 at 100. These two types of encrypted communication links (SSL and SGC) are a hierarchy of encrypted communication links because one provides a greater level of security than the other. Also, IE5 Resource Kit discusses several other types of encrypted connection links that can be made by the computer running Windows 2000, including links encrypted using Fortezza, Transport Layer Security, and Private

Communications Technology. Ex. 1006 at 9. Thus, Windows Resource Kit in view of IE5 Resource Kit and Elgamal, renders obvious claim 30 .

D.

No Secondary Considerations Exist

59

Petition in IPR2015-01009 and Elgamal, renders obvious each of the challenged claims of the ’643 patent. No secondary indicia of non-obviousness exist having a nexus to the putative

“invention” of the ’643 patent contrary to that conclusion. Petitioner reserves its right to respond to any assertion of secondary indicia of non-obviousness advanced by Patent Owner.

V.

Conclusion

Petitioner respectfully submits that the evidence presented in this Petition establishes a reasonable likelihood that Petitioner will prevail in establishing the challenged claims are unpatentable, and requests that Trial be instituted.

Jeffrey P. Kushan

Registration No. 43,401

Sidley Austin LLP

1501 K Street NW

Washington, DC 20005

jkushan@sidley.com

Attorney for Petitioner

60


PETITION FOR INTER PARTES REVIEW

OF U.S. PATENT NO. 8,843,643

Attachment A:

Proof of Service of Petition


CERTIFICATE OF SERVICE

I hereby certify that on this 28th day of April, 2015, copies of this Petition for Inter Partes Review, Attachments and Exhibits have been served in its entirety by Federal Express on the following counsel of record for Patent Owner:

VirnetX, Inc.

P.O. Box 439

308 Dorla Court

Zephyr Cove, Nevada 89448

Toby H. Kusmer

McDermott Will & Emery LLP

28 State Street

Boston, MA 02109-1775

Toby H. Kusmer

McDermott Will & Emery LLP

The McDermott Building

500 North Capitol Street, N.W.

Washington, D.C. 20001

Joseph E. Palys

Paul Hastings LLP

875 15 th

Street, NW


Naveen Modi

Paul Hastings LLP

875 15 th

Street, NW


Jason E. Stach

Finnegan, Henderson, Farabow,

Garrett & Dunner, LLP

3500 SunTrust Plaza

303 Peachtree Street, NE

Atlanta, GA 30308-3263

Dated: April 28, 2015

/Jeffrey P. Kushan/

Jeffrey P. Kushan

Reg. No. 43,401

Attorney for Petitioner Apple


PETITION FOR INTER PARTES REVIEW

OF U.S. PATENT NO. 8,843,643

Attachment B:

Exhibit List


Exhibit # Reference Name

1001 U.S. Patent 8,843,643

1002 U.S. Patent 8,843,643 File History

1004

1005

1007

1008

1010

1011

1012

1013

1014

1015

1016

1017

1018

1019

Curriculum Vitae of Roberto Tomassia

Microsoft Corp., Microsoft Windows 2000 Professional Resource Kit

(2000)

U.S. Patent 5,657,390

Publication - Web Server Technology; Yeager & McGrath (1998)

Registration Request

USPN 6,839,750 (Control No. 95/001747) Request for Inter Partes

Reexamination

USPN 6,839,759 (Control No. 95/001747) Patent Owner’s Response to 10/14/2011 Office Action

VirnetX v Cisco - Opening Claim Construction Brief (TXED 6-10-cv-

417; Dkt 173)

VirnetX v Cisco - Claim Construction Order (TXED 6-10-cv-00417;

Dkt 266)

Microsoft Windows 2000 Professional Resource Kit – About page

U.S. Patent No. 6,502,135


Amazon Reviews “Microsoft Windows 2000 Professional Resource

Kit”

Barnes and Noble Customer Reviews of “Microsoft Windows 2000

Professional Resource Kit”

Microsoft Press Announces Complete Line of Learning and Reference

Solutions for Microsoft Windows 2000 (Feb. 17, 2000), http://news.microsoft.com/2000/02/17/microsoft-press-announcescomplete-line-of-learning-and-reference-solutions-for-microsoftwindows-2000/

1028

1029

1030

1031

1032

1033

1034

1035

1036

1037

1038

1039

1040



1020 RFC 2026 – The Internet Standards Process – Revision 3

1021

1022

1023

1024

1025

1026


RFC 882 – Domain Names – Concepts and Facilities

RFC 883 – Domain Names – Implementation and Specification

RFC 1034 – Domain Names – Concepts and Facilities

RFC 1035 – Domain Names – Implementation and Specification

RFC 1912 – Common DNS Operational and Configuration Errors http://www.tldp.org/HOWTO/html_single/NET3-4-HOWTO/ (Aug.

1999)

RFC 2219 – Use of DNS Aliases for Network Services

RFC 2543 – SIP: Session Initiation Protocol


Ben Laurie & Peter Laurie, Apache: The Definitive Guide (2d ed.

1999)

Kerberos: An Authentication Service for Open Network Systems

(Mar. 30, 1988)

RFC 2409 – The Internet Key Exchange (IKE)

RFC 2408 – Internet Security Association and Key Management

Protocol (ISAKMP)

RFC 2401 – Security Architecture for Internet Protocol


Original Specification, U.S. Utility Patent Application No. 09/558,210

Microsoft Internet Explorer 5 Resource Kit - Copyright Registration

Amazon reviews “Microsoft Windows 2000 Server Resource Kit”

Secure Sockets Layer for SOCKS Version 5 (1997)



1041

1042

1043

1044

Ari Luotonen & Tim Berners-Lee, CERN httpd Reference Manual

(1994)

Archive.org snapshot of Morgan Kaufmann Publishers website, www.mjp.com (April 29, 1997), https://web.archive.org/web/

19970429195411/http://www.mkp.com/index.htm

Search for “‘web server technology’ yeager”, Google Scholar, https://scholar.google.com/ (date limited: 1996-1999)


IPR2015

Related documents

Products

Support

IPR2015

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib