Petition for Inter Partes Review of U.S. Patent No. 6,502,135 UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD

Transcription

1 Paper No. 1 UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD RPX Corporation, Petitioner, v. VirnetX, Inc. and Science Application International Corporation, Patent Owner Patent No. 6,502,135 Issued: Dec. 31, 2002 Filed: Feb. 15, 2000 Inventors: Edmund C. Munger, et al Title: Agile Network Protocol For Secure Communications With Assured System Availability Inter Partes Review No. IPR PETITION FOR INTER PARTES REVIEW

2 TABLE OF CONTENTS I. Compliance with Requirements for a Petition for Inter Partes Review... 1 A. Certification the 135 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)) Real Party in Interest ( 42.8(b)(1)) Other Proceedings ( 42.8(b)(2)) Designation of Lead and Backup Counsel Service Information ( 42.8(b)(4))... 5 D. Proof of Service ( 42.6(e) and (a))... 5 II. Identification of Claims Being Challenged ( (b))... 5 III. Relevant Information Concerning the Contested Patent... 6 A. Effective Filing Date and Prosecution History of the 135 patent... 6 B. Person of Ordinary Skill in the Art... 8 C. Construction of Terms Used in the Claims Virtual Private Network (VPN) (Claims 1, 10, 13, 18) Virtual Private Link (Claim 13) Domain Name (Claims 1, 10, 18) Domain Name Service (Claims 1, 10, 13, 18) DNS Request (Claims 1, 3-5, and 18) DNS Server (Claims 18, 2 and 8) DNS Proxy Server (Claims 10, 8) Secure Web Site/Target Web Site (Claims 1, 8, 10, 18) Web Site (Claims 1, 10, 18) Secure Web Computer (Claim 10) Target Computer (Claims 1, 10, 18) IP Address Hopping Scheme (Claim 6)...17 i

3 13. Determining (Claims 1, 3-5, and 18) Client Computer (Claims 1-7, 9-13, 17, and 18) Transparently (Claims 1, 10, and 18) Automatically Initiating the VPN (Claims 1, 4, 5, and 18) Passes Through the DNS Request (Claim 8) Gatekeeper Computer (Claims 7 and 10-12) Allocates VPN Resources (Claims 7, 10, and 13)...20 IV. Precise Reasons for Relief Requested A. Claims 1-10, and 18 Are Anticipated By Aventail (Ex. 1007) Aventail Anticipates Claim Aventail Anticipates Claim Aventail Anticipates Claim Aventail Anticipates Claim Aventail Anticipates Claim Aventail Anticipates Claim Aventail Anticipates Claim 4 and Aventail Anticipates Claim Aventail Anticipates Claim Aventail Anticipates Claim Aventail Anticipates Claim Aventail Anticipates Claim Aventail Anticipates Claim 14 and B. Aventail Connect In View of Aventail Extranet Center Renders Claims 1-10, and 18 Obvious C. Aventail In View of RFC 1035 Renders Claims 4, 5, and 18 Obvious D. Aventail In View of Reed I Renders Claims 6, 14 and 15 Obvious ii

4 E. Claims 1-4, 7, 8, 10, and 12 Are Anticipated by Kiuchi (Ex. 1066) Kiuchi Anticipates Claim Kiuchi Anticipates Claim Kiuchi Anticipates Claim Kiuchi Anticipates Claim Kiuchi Anticipates Claim Kiuchi Anticipates Claim Kiuchi Anticipates Claim Kiuchi Anticipates Claim F. Kiuchi In View of RFC 1034 Renders Claims 5, 8, and 18 Obvious V. Conclusion Attachment A. Proof of Service of the Petition Attachment B. List of Evidence and Exhibits Relied Upon in Petition iii

5 I. Compliance with Requirements for a Petition for Inter Partes Review A. Certification the 135 Patent May Be Contested by Petitioner Petitioner certifies that U.S. Patent No. 6,502,135 (the 135 patent) (Ex. 1001) is available for inter partes review. Petitioner certifies that it is not barred or estopped from requesting inter partes review of the claims of the 135 patent on the grounds identified in this Petition. Neither Petitioner, nor any party in privity with Petitioner, has filed a civil action challenging the validity of any claim of the 135 patent. As explained in C.1, below, the 135 patent has not been the subject of a prior inter partes review by Petitioner or a privy of Petitioner. Neither Petitioner, nor any party in privity with Petitioner, has been served with a complaint alleging infringement of any claim of the 135 patent. 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 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 RPX Corporation ( RPX ) located at One Market Plaza, Steuart Tower, Suite 800, San Francisco, California RPX is the leading provider of patent risk solutions, offering defensive buying, acquisition syndication, patent intelligence, insurance services, and

6 advisory services. RPX has over 160 clients who have availed themselves of its services, which include, inter alia, market intelligence, patent strategy services, and defensive patent acquisition and licensing. 1 As part of its mission to achieve a more rational patent marketplace, RPX pursues efforts to improve patent quality and reduce patent litigation. For example, RPX has established a Research & Development program ( RPX R&D ) through which it advances a variety of initiatives to address and improve patent quality. The initiatives under this program include increasing transparency by collecting information regarding enforcement activities of entities or patents, tracking patent sales, collecting and evaluating prior art, and compiling databases of this information, which RPX makes available to its clients. In addition, as part of its RPX R&D program, RPX contests patents of questionable validity by filing requests for post-issuance review with the PTO. See RPX has solicited contributions from its clients to help fund its RPX R&D service through an addendum agreement which is being filed under seal with this 1 RPX observes that the 135 patent has been asserted against some of its clients. 2

7 petition. Ex As reflected in the addendum agreement, RPX has sole discretion over and controls the decision of which patents to contest through PTO post-issuance proceedings, the grounds that are raised in any petition filed by RPX requesting initiation of such proceedings, the conduct of RPX in such proceedings and the decision to continue or terminate the participation of RPX in any such proceeding. RPX also is solely responsible for payment of any expenses of preparing and filing petitions seeking post-issuance review of patents, and for any expenses associated with any proceedings that result from such petitions. RPX has exercised its sole discretion in deciding to file the present petition concerning the 135 patent and was solely responsible for selecting the claims of the 135 patent being challenged and the grounds presented in it. RPX alone shall control the participation of RPX in any proceeding initiated on the basis of this petition, and alone shall control any decision by RPX to continue or terminate its participation in any proceeding established on the basis of this petition. In addition, RPX alone is responsible for paying the costs of preparing and filing this petition, and for any subsequent costs in connection with any proceeding established on the basis of this petition. RPX, thus, is the sole real party in interest of the present petition and is not in privity with any other entity in connection with 2 An executed copy of the agreement is also being filed under seal. Ex

8 this petition. 2. Other Proceedings ( 42.8(b)(2)) The 135 patent is the subject of a number of civil actions including: (i) Civ. Act. No. 6:13-cv LED (E.D. Tex.), filed February 26, 2013; (ii) Civ. Act. No. 6:12-cv LED (E.D. Tex.), filed November 6, 2012; (iii) Civ. Act. No. 6:10-cv LED (E.D. Tex.), filed August 11, 2010; (iv) Civ. Act. No. 6:11-cv LED (E.D. Tex), (iv) Civ. Act. No. 6:13-cv LED (E.D. Tex), filed April 22, 2013; (v) Civ. Act. No. 6:10-cv (E.D. Tex); and (vi) Civ. Act. No. 6:07-cv (E.D. Tex). The 135 patent is also the subject of merged inter partes reexamination nos. 95/001,679 and 95/001,682. In the merged proceedings, the Office recently issued a Non-Final Action rejecting all 18 claims of the 135 patent, including rejections based on, inter alia, Ex (Aventail), Ex (Beser), and Ex (Kiuchi). The 135 patent also was subject to reexamination no. 95/001,269, which is over. The 135 patent also is the subject of IPR petitions No. IPR and IPR filed by Apple Inc., and IPR filed by New Bay Capital LLC. Finally, the 135 patent is the subject of IPR petition No. IPR being filed concurrently with the present Petition. Petitioner observes that the grounds presented in this petition, and in IPR petition IPR closely parallel the grounds presented in the petitions filed by Apple and New Bay Capital. 4

9 3. Designation of Lead and Backup Counsel Lead Counsel Greg Howison Reg. No Backup Lead Counsel Peter J Thoma Reg. No pthoma@dalpat.com Service Information ( 42.8(b)(4)) Service on Petitioner may be made by mail to: Howison & Arnott, L.L.P. P.O. Box Dallas, Texas Service on Petitioner may be made by hand delivery to: Howison & Arnott, L.L.P. Lincoln Centre II 5420 LBJ Freeway, Suite 660 Dallas, Texas The fax number for lead and backup counsel is D. Proof of Service ( 42.6(e) and (a)) Proof of service of this petition is provided in Attachment A. II. Identification of Claims Being Challenged ( (b)) Claims 1-10, 12-15, and 18 of the 135 patent are unpatentable as being anticipated under 35 U.S.C. 102(a), (b), & (e), and/or for being obvious over the prior art under 35 U.S.C Specifically: (i) (ii) Claims 1-10, 12-15, and 18 are anticipated under 102(b) by Aventail Connect v 3.01/2.5 Administrator s Guide ( Aventail ) (Ex. 1007); Claims 1-10, 12-15, and 18 are obvious under 103 based on 5

10 Aventail (Ex. 1007); (iii) (iv) (v) (vi) Claims 4, 5 and 18 are obvious under 103 based on Aventail (Ex. 1007) in view of RFC 1035 (Ex. 1017); Claims 6, 14 and 15 are obvious under 103 based on Aventail (Ex. 1007) in view of Reed (Ex. 1014); Claims 1-4, 7, 8, 10, and 12 are anticipated under 102(b) by Takahiro Kiuchi and Shigekoto Kaihara, C-HTTP - The Development of a Secure, Closed HTTP-based Network on the Internet, the Proceedings of SNDSS 1996 ( Kiuchi ) (Ex. 1066); Claims 5, 8, and 18 are obvious under 103 based on Kiuchi (Ex. 1066) in view of RFC 1034 (Ex. 1016). Petitioner s proposed construction of the contested claims, the evidence relied upon, and the precise reasons why the claims are unpatentable are provided in IV, below. The evidence relied upon in this petition is listed in Attachment B. Petitioner requests expedited briefing during the preliminary proceedings. The grounds of Petitioner s challenge are substantially identical to the grounds advanced by the petitioners in IPR , IPR , and IPR Patent Owner already has filed a preliminary response in each of those proceedings that addresses the claim constructions, prior art references, and grounds of invalidity advanced in this petition. Petitioner observes the Board has discretion to set the deadline for any preliminary response. 35 U.S.C III. Relevant Information Concerning the Contested Patent A. Effective Filing Date and Prosecution History of the 135 patent 6

11 The 135 patent issued from U.S. Application No. 09/504,783, filed February 15, The 783 application is a continuation-in-part of U.S. Application No. 09/429,653, filed on October 29, The 783 and 653 applications each claim priority to Provisional Application Nos. 60/106,261, filed October 30, 1998 and 60/137,704, filed June 7, Claims 1, 10, 13 and 18 are the independent claims. Claims 1, 10 and 18 rely on information first presented in the 783 CIP application. For example, claim 1 specifies generating from the client computer a Domain Name Service (DNS) request and subsequent steps involving that DNS request, while claim 10 specifies [a] system comprising a DNS proxy server Applications filed prior to the 783 application do not contain the term domain name service much less describe systems using DNS requests or DNS proxy servers to establish VPNs. Ex at Claim 13 likewise relies on information first presented in the 783 application. For example, it specifies receiving from one of the plurality of client computers a request to establish a connection and authenticating, with reference to one of the plurality of authentication tables, that the request received in step (1) is from an authorized client. Neither step is described in any application filed before the 783 application. Ex at Accordingly, the effective filing date of claims 1-10, and 18 is no earlier than February 15, Ex at 61. 7

12 B. Person of Ordinary Skill in the Art A person of ordinary skill in the art in the field of the 135 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 at 68. C. Construction of Terms Used in the Claims In an IPR, claims must be given their broadest reasonable construction in light of the specification. 37 CFR (b). To do this, the Board should consider subject matter that Patent Owner contends infringes the claims, and constructions Patent Owner has advanced in litigation. Petitioner also notes the specification has not expressly defined any of the claim terms. Consequently, the words in the claims should be used to determine the broadest reasonable construction. [I]t is the Patent Owner s burden to precisely define the invention in the claims. AirCraft Medical LTD. v. Verathon Inc., Reexam. Control No. 95/000,161, Appeal , p. 16 (PTAB Dec. 11, 2012) (citing In re Morris, 127 F.3d 1048, 1056 (Fed. Cir. 1997)). Of course, the specification must 8

13 also be consulted to determine the broadest reasonable construction of the claims. 1. Virtual Private Network (VPN) (Claims 1, 10, 13, 18) Petitioner agrees with New Bay Capital that the broadest reasonable construction of virtual private network or VPN is a private network that is configured within a public network. This construction is consistent with the construction proposed by petitioner Apple (i.e., a VPN is a network of computers which privately communicate directly or otherwise with each other on insecure paths between the computers where the communication is both secure and anonymous, where the data transferred may or may not be encrypted. ). Petitioner would also support the Apple construction, if the Board determines that is the broadest reasonable construction of VPN. Patent Owner proposes a construction of VPN that differs in two respects; namely, that it requires (i) encryption, and (ii) computers in the VPN to directly communicate with each other. Ex at 22. Both positions are inconsistent with the broadest reasonable construction of VPN. Initially, the 135 patent does not define the term VPN. Ex at 194. Before 2000, the term VPN did not have a single accepted meaning. For example, two authors observed in a 1998 paper that [t]he wonderful thing about virtual private networks is that its myriad definitions give every company a fair chance to claim that its existing product is actually a VPN. Ex at 2. 9

14 Despite this, these authors did recognize that VPNs create a private network using encryption and/or tunneling techniques. Ex at 2 ( But no matter what definition you choose, the networking buzz-phrase doesn't make sense. The idea is to create a private network via tunneling and/or encryption over the public Internet. ). This reflects the commonly held view before 2000 that a VPN could be established by using obfuscation or hiding techniques, by encryption, or both, and that by doing so, one could ensure the security and anonymity of network traffic over the public network. See Ex at The 135 patent also explains that one can provide data security using IP hopping schemes, rather than solely by using encryption. As it states, Data security is usually tackled using some form of data encryption. Ex at 1:38-39 (emphasis added). The 135 patent also illustrates use of a quasi-random IP hopping scheme to implement a VPN. See, e.g., id. at 23:10-14 ( In a second mode referred to as promiscuous per VPN mode, a small set of fixed hardware addresses are used, with a fixed source/destination hardware address used for all nodes communicating over a virtual private network. (Emphasis added)). Nowhere in this section of the 135 patent is there any mention of using encryption to establish the VPN. Moreover, claim 6 relies on this particular embodiment, specifying that step 3 of claim 1 comprises the step of establishing the VPN by creating an IP address hopping scheme between the client computer and the target 10

15 computer. Id. at 47:53-55 (emphasis added); see also id. at 2:25-36 (explaining use of anonymity techniques); Ex at Also, the 135 patent explains that TARP routers (which do encrypt traffic) are simply one way to implement VPNs. E.g., Ex at 38:2-5 ( The VPN is preferably implemented using the IP address hopping features of the basic invention described above (emphasis added)); id. at 2:66-3:29. The 135 patent also does not list any encryption steps in describing its VPN processes. See id. at 37:17-40:13. To support its contention that a VPN requires encryption Patent Owner points to the term FreeS/WAN in one passage of the 135 patent. Ex at 37: That passage, however, does not define what a VPN is, but simply explains that RFC 2535 (the FreeS/WAN protocol) can be used to implement one type of a VPN. See id. Notably, Patent Owner does not cite to any passage of RFC 2535 (Ex. 1068) the publication actually cited in the 135 patent to support its assertions. This is because RFC 2535 does not even mention the terms encryption or VPN, much less state that a VPN must use encryption. Patent Owner also points to the construction adopted by certain District Courts that a VPN is a network of computers which privately and directly communicate with each other by encrypting traffic on insecure paths between the computers where the communication is both secure and anonymous. Ex at 8. This construction, however, is not the broadest reasonable construction, but 11

16 reflects the ordinary meaning of the term as used in district court litigation; it is not controlling in this proceeding. The broadest reasonable construction of VPN thus does not require encryption, but can establish a private network using either encryption or routing techniques (e.g., tunneling or obfuscation ), or both. Patent Owner next contends that a VPN requires computers in a VPN to directly communicate with each other. E.g., Ex at 1-3 (emphasis added). In the August 2010 litigation, the Court found that Patent Owner had disclaimed VPNs that do not involve direct communications between the involved computers. Id. at 6; see Ex at 6-9; Ex at 5-7. The Court relied on Patent Owner s statements to the Office during the 269 reexamination proceeding involving the 135 patent to make this determination; specifically, that the 135 claims were not anticipated by the Aventail systems because computers connected according to Aventail do not communicate directly with each other. 3 (Emphasis added). The Court also observed that routers, firewalls, and similar servers that participate in typical network communication do not impede direct 3 As explained below in IV.A.1, that belief rested on a mischaracterization of Aventail by Patent Owner during the reexamination. In reality, Aventail clearly shows computers directly addressing other computers within the VPNs, which means the computers will directly communicate with each other per the claims. 12

17 communication between a client and target computer. Ex at 8 (FN2). As petitioner Apple has explained, the Court s finding that Patent Owner disclaimed a portion of the literal scope of the 135 patent claims (i.e., that covering VPNs in which computers do not directly communicate) means that the 135 claims in their broadest reasonable construction must still encompass this subject matter. IPR , Petition at Patent Owner s prosecution disclaimer is effective in a district court proceeding but not here. E.g., M.P.E.P. 2111; id. at (I) ( Although claims of issued patents are interpreted in light of the specification, prosecution history, prior art and other claims, this is not the mode of claim interpretation to be applied during examination. ). The broadest reasonable construction of VPN therefore encompasses a network of computers which privately communicate directly or otherwise with each other on insecure paths between the computers where the communication is both secure and anonymous, where the data transferred may or may not be encrypted. 2. Virtual Private Link (Claim 13) The 135 patent does not define the term virtual private link. The district court found this term means the same thing as a VPN. Ex at 8-9. In the pending IPRs, Patent Owner did not dispute this finding. Ex at 26. Consequently, Petitioner submits the same construction should be used for virtual private link as is used for virtual private network. 13

18 3. Domain Name (Claims 1, 10, 18) The 135 patent does not define the term domain name. A person of ordinary skill in the art would understand that a domain name is a name corresponding to an IP address. Ex at Petitioner therefore agrees with Apple s proposed construction. Also, Patent Owner has asserted in court that a domain name means a name corresponding to an IP address. Ex at The district court adopted Patent Owner s construction, and therefore, Patent Owner now is estopped from arguing for a different construction (as it attempts to do in Ex at 27-29). See Data General Corp. v. Johnson, 78 F.3d 1556, 1565 (Fed. Cir. 1996). Furthermore, claims 1, 10, and 18 expressly provide that the domain name is used to access an IP address. 4. Domain Name Service (Claims 1, 10, 13, 18) The 135 patent does not define the phrase domain name service. Patent Owner has asserted a domain name service is a lookup service that returns an IP address for a requested domain name. Ex at A person of ordinary skill in the art also would recognize that a domain name service performs domain name resolution according to Internet standards, namely, RFC 1034 (Ex. 1016) and RFC 1035 (Ex. 1017). Ex at Under these standards, an IP address will not always be returned an error also may be returned. Ex at Thus, the broadest reasonable construction of domain name service 14

19 includes a lookup service that will return an IP address or an error code in response to a domain name resolution request. In its oppositions to the Apple and New Bay petitions, Patent Owner contends a domain name service is not an independent term, but rather, is part of the term domain name service (DNS) request. Ex at That contention is inconsistent with the claim language. Claim 1 defines DNS as an abbreviation for domain name service. Several other claims use DNS as an adjective to describe other devices, e.g., a DNS server (claim 2) or DNS proxy server (claim 8). The claims thus define DNS as a distinct term from DNS request, and the Board should reject Patent Owner s illogical proposed construction which seeks to avoid construing DNS (see Ex at 29). 5. DNS Request (Claims 1, 3-5, and 18) The 135 patent does not explicitly define the term DNS request. Consistent with the definition of domain name service, see 4, above, a DNS request is a request to resolve a domain name into an IP or a network address. 6. DNS Server (Claims 18, 2 and 8) The 135 patent does not define the term DNS Server. However, the way the term is used in the 135 patent indicates a DNS Server is a server that returns an IP address in response to a request containing a domain name. See Ex at As noted in 4, a domain name service also may return an 15

20 error. Thus, Petitioner agrees with Apple that the broadest reasonable construction of DNS server includes a computer or computer-based process that will return an IP address or an error code in response to a domain name resolution request. 7. DNS Proxy Server (Claims 10, 8) Petitioner agrees with Patent Owner that the broadest reasonable construction of a DNS proxy server is a computer or program that responds to a domain name inquiry in place of a DNS. Ex at 16-17; Ex at Petitioner notes that Patent Owner has admitted that the DNS proxy server can be distributed across different computers or processes. Ex at Secure Web Site/Target Web Site (Claims 1, 8, 10, 18) Petitioner agrees with Patent Owner and Apple that the broadest reasonable construction a secure web site is a computer associated with a domain name and that can communicate in a virtual private network. Ex at 21-22; Ex at Petitioner also agrees with Patent Owner and Apple that broadest reasonable construction a secure target web site is a target computer associated with a domain name and that can communicate in a virtual private network. Ex at 21-22; Ex at Web Site (Claims 1, 10, 18) The 135 patent does not define the term web site. Patent Owner asserted a web site means a computer associated with a domain name and that can communicate in a network. Ex at Petitioner agrees that the broadest 16

21 reasonable construction of web site includes Patent Owner s construction. 10. Secure Web Computer (Claim 10) Petitioner agrees with Patent Owner and Apple that the broadest reasonable construction of a secure web computer is a computer that requires authorization for access and that can communicate in a virtual private network. Ex at 22-24; Ex at Target Computer (Claims 1, 10, 18) The 135 patent does not define the term target computer. Patent Owner has asserted this term can mean a computer with which the client computer seeks to communicate. Ex at 24-25; see Ex (Preliminary Response) at Patent Owner also has admitted the web site and secure target web site do not need to be on the same machine as the target computer. Ex at Thus, the broadest reasonable construction of target computer is a computer with which the client computer seeks to communicate. 12. IP Address Hopping Scheme (Claim 6) The 135 patent does not define the term IP address hopping scheme. It does refer to a variety of schemes that route traffic through intermediary network devices according to a pre-defined scheme as IP hopping schemes. See, e.g., Ex at 5:30-64, 14:59-16:15. These schemes use a wide variety of routing concepts and strategies that are used to obfuscate the IP address of the sender, receiver, or both. Ex at 198, 200. The broadest reasonable construction 17

22 of IP address hopping scheme thus encompasses any type of scheme that routes IP traffic from a client to the destination through intermediary devices. Patent Owner s proposed construction differs by adding the phrase in a way that creates a VPN. This construction is illogical the claims that use IP hopping scheme clearly state that a VPN is being created which uses that scheme. See, e.g., Ex at claim 6 ( wherein step (3) comprises the step of establishing the VPN by creating an IP address hopping scheme ); id. at claim 11 ( The system of claim 10, wherein the gatekeeper computer creates the VPN by establishing an IP address hopping regime ). Patent Owner s additional terms are unnecessary and would only cause confusion. 13. Determining (Claims 1, 3-5, and 18) Petitioner agrees with Patent Owner that the ordinary meaning of the term determining should be used. Ex at 42. Petitioner also agrees with Patent Owner that the determining step can be made by a client computer or by another computer participating in a VPN. See Ex at 42 ( It is sufficient to note, as the district court did, that nothing in claim 1 prevents the client computer from performing the determining step. ). 14. Client Computer (Claims 1-7, 9-13, 17, and 18) The 135 patent does not define the term client computer. The claims use the term client computer to refer to a computer that sends the request that 18

23 initiates a VPN with a target computer e.g., in claim 1 the client computer generates a DNS request, and in claim 13 one of a plurality of client computers generates a request to establish a connection. The logical meaning of client computer from the claims is simply the computer that sends the request that initiates the VPN. Patent Owner, however, asserts a client computer is the user s computer. Ex at Patent Owner s definition is inconsistent with the claim language: the term used in the claims is not the client s computer but rather the client computer. Also, the District Court in concurrent litigation recognized that intermediary computers participate in VPNs. See, e.g., Ex.1049 at 8 n.2. Petitioner thus agrees with New Bay Capital that the broadest reasonable construction of client computer is a computer that generates or sends a request to initiate a VPN with a target computer, whether or not that is a user s computer. 15. Transparently (Claims 1, 10, and 18) The 135 patent does not define the term transparently, which appears in the preamble of independent claims 1, 10, and 18. Patent Owner and New Bay assert the term means that the user need not be involved in creating the [secure link]/[virtual private network]. Patent Owner also contends, contrary to what the District Court found, that transparently provides antecedent basis for three different terms (VPN, client computer, and target computer), making the preamble a limiting part of the claim. Ex at Yet, in related litigation, the 19

24 District Court found that transparently is merely descriptive of what is found in steps (2) and (3) of claim 1. Ex at 11. The Court s finding is relevant to determining the broadest reasonable description here it confirms that the term transparently does not add any substantive meaning to the claims. A construction is also unnecessary in view of the construction of automatically initiating the VPN below. 16. Automatically Initiating the VPN (Claims 1, 4, 5, and 18) Petitioner agrees with Patent Owner and New Bay Capital that the broadest reasonable construction automatically initiating the VPN is initiating the VPN without involvement of a user. Ex at 47; see Ex at Passes Through the DNS Request (Claim 8) Petitioner agrees with Patent Owner and Apple that passes through the request to a DNS server should be given its plain and ordinary meaning and requires no construction. Ex at Gatekeeper Computer (Claims 7 and 10-12) Petitioner agrees with Patent Owner and Apple that gatekeeper computer should be given its plain and ordinary meaning and requires no construction. Ex at Allocates VPN Resources (Claims 7, 10, and 13) Petitioner agrees with Patent Owner and Apple that allocates VPN resources, allocates resources for the VPN, and allocating resources to 20

25 establish a virtual private link should be given their plain and ordinary meaning and require no construction. Ex at 50. IV. Precise Reasons for Relief Requested A. Claims 1-10, and 18 Are Anticipated By Aventail (Ex. 1007) Aventail (Ex. 1007) is a printed publication that was publicly distributed no later than January 31, Ex at ; Ex at 11-36; Ex at Aventail is prior art to the 135 patent at least under 35 U.S.C. 102(a) and (b). A concise summary of the systems and processes described in Aventail is provided at 300 to 393 of Ex and at 37 to 81 of Ex The Aventail publication consists of two documents that cross-reference each other extensively; namely, the Aventail Connect v3.01/v2.51 Administrator s Guide ( Aventail Connect ) and the Aventail Extranet Center v3.0 Administrator s Guide ( Aventail Extranet Center ). See Ex at The two documents were distributed together with software installation media as part of a single commercial product. See Ex at ; Ex at The two documents describe the configuration and operation of client and server components of a single Aventail VPN system. See Ex at ; Ex at The documents together, thus, constitute a single publication, Aventail (Ex. 1007). If the Board determines the two documents do not constitute a single printed publication, the Board should treat Aventail as consisting of the 21

26 Aventail Connect document, which incorporates by reference specific portions of the Aventail Extranet Center document. See Ex at 256; Ex at Aventail Anticipates Claim 1 Aventail describes processes that automatically and transparently establish a VPN between a client computer and a remote private network in response to a user specifying a secure destination in a connection request. Ex at Aventail therefore shows [a] method for transparently creating a virtual private network (VPN) between a client computer and a target computer. Ex at ; see generally Ex at Aventail explains that Aventail Connect running on a client computer intercepts each connection request whether it contains a domain name or an IP address and evaluates the request. Ex at 307, , If the request specifies a destination in a domain matching a domain name in a redirection rule, the Aventail system establishes a VPN between the client computer and the secure destination. Ex at , 324, Aventail thus discloses the step of generating from the client computer a Domain Name Service (DNS) request that requests an IP address corresponding to a domain name associated with the target computer. Aventail explains redirection rules are used to identify connection requests made on a client computer containing a domain name or IP address requiring 22

27 secure communications. Ex at , , Redirection rules contain domain names or IP addresses associated with destinations requiring secure communications. Ex at , A client computer running Aventail Connect could either evaluate connection requests locally, or could proxy all connection requests to a proxy server (the Aventail Extranet Server or AES ) for handling. Ex at , , Aventail thus describes a process including a step of of determining whether the DNS request transmitted in step (1) is requesting access to a secure web site. See generally Ex at Aventail shows that if a domain name or IP address in a DNS request matches a redirection rule, the request will be flagged for special handling by the Aventail Connect client (e.g., by inserting a false entry ( HOSTENT ) in the request). Ex at , 342, Then, after the name resolution step, the request will be evaluated if it contains the false entry or an IP address matching a redirection rule, the client would know the request would have to be sent ( proxied ) to the proxy server (AES) specified in the redirection rule for that domain name or IP address. Ex at To do this, the client computer would open a connection to the proxy server and authenticate the user. Ex at If authentication was successful, the original request would be sent to the server, and communications would proceed. Aventail also 23

28 explains that communications between the client and the private network would be automatically encrypted/decrypted. Ex at , 357. Aventail thus describes a process including the step of in response to a determination that the DNS request is requesting access to a secure target web site, automatically initiating the VPN between the client computer and the target computer. Ex at Aventail shows computers in a VPN will communicate directly with each other as the Court found in the August 2010 litigation. For example, Aventail shows an Aventail Connect client configured via its Extranet Neighborhood feature can, via a VPN, directly interact with specific computers and other resources on a private Windows network. Ex at Aventail shows this can be done by configuring a client computer running Aventail Connect to store or retrieve data about the internal network locations of hosts on the internal Windows network. Ex at Aventail thus anticipates claim 1 as it shows a process including all of the steps specified in that claim. 2. Aventail Anticipates Claim 10 Aventail describes systems in which transparently establish VPNs between a client computer running Aventail Connect and a corporate network via a proxy server ( AES ). Ex at , Network traffic between the client and corporate network is automatically encrypted/decrypted. Ex at 24

29 , 357. Also, Aventail describes systems that enable a client computer running Aventail Connect and its Extranet Neighborhood feature to directly communicate with specific computers (e.g., hosts) on an internal network. See 1, above; Ex at Aventail thus describes a system that transparently creates a virtual private network (VPN) between a client computer and a secure target computer. See generally Ex at Aventail shows a client computer running Aventail Connect will intercept and evaluate connection requests. Ex at 307, , This is the same technique described in the 135 patent. See Ex at 38:23-33; see also Ex (Aventail) at 316. Aventail also shows the evaluation of a request may be performed by the client computer or a DNS proxy server (Aventail Extranet Server). Ex at (client computer); (Extranet Server). For example, a client computer can be configured to route all connection requests to the Aventail proxy server for handling and resolution by enabling the DNS Proxy Option in the Aventail Connect client. Ex at 317, , , Alternatively, the Aventail Connect client can be configured to evaluate connection requests locally. Ex at , A DNS Proxy Server can be on the same or a different computer as the one where the request originates. See III.C.6; see also Ex at It also can be a process which is performed on a single computer or by several computers 25

30 working together. See III.C.6; Ex at Thus, the client computer running Aventail Connect, the server computer running AES, or both working together, can be a DNS proxy server within the broadest reasonable construction of claim 10. See III.C.6; Ex at Aventail describes systems that determine if a connection request contains a domain name or an IP address that matches a redirection rule, and if it does, will establish a VPN between the client computer and the private network specified in the request. Ex at , 324, This process involves sending a request from the client computer to the AES. Ex at , Aventail also shows that if a request contains a domain name or IP address that does not match a redirection rule or matches an entry in a local domain resolution rule, the request is passed through to the operating system of the client computer for handling. Ex at , , 350, 353. Aventail thus shows a DNS proxy server that receives a request from the client computer to look up an IP address for a domain name, wherein the DNS proxy server returns the IP address for the requested domain name if it is determined that access to a non-secure web site has been requested, and wherein the DNS proxy server generates a request to create the VPN between the client computer and the secure target computer if it is determined that access to a secure web site has been requested. Ex at

31 Aventail explains its systems include a DNS proxy server (AES). Ex at 317, , , The AES is a gateway computer because it is connected both to a private network and the Internet, and will pass authorized network traffic from one network over to the other. Ex at 302, , It The AES receives and evaluates requests from client computers, handles authentication and encryption of data sent between it and the client computer, and routes traffic to specified destinations on the private network. Id. Ex at Aventail thus describes a system comprising a gateway computer that allocates resources for the VPN between the client computer and the secure web computer in response to the request by the DNS proxy server. Because Aventail describes systems having all the elements specified in claim 10, it anticipates this claim under 102(b). See Aventail Anticipates Claim 13 Aventail describes systems in which client computers gain access to and communicate with computers on a private network via a gateway computer (the AES). Ex at 302, , Aventail shows multiple remote client computers may access corporate network resources. Id. The AES authenticates each client computer before establishing a VPN involving that client computer. Ex at 302, 308, The AES can be configured to use a 27

32 variety of authentication techniques, all of which function to test whether a known user has presented correct credentials. Ex at 307, Aventail explains the Aventail Extranet Server is configured by defining users and/or groups of users, setting access control policies for users and defining authentication rules to determine if users are granted access to a network to which the AES is regulating access. Ex at 339, Also, the AES can be configured to enforce policies that determine which users can remotely gain access to a protected network, what resources each user will be allowed to access, and other variables. Id. The AES will use both user credentials and attributes of a client computer to evaluate connection requests. Ex at 370. The AES stores its settings in configuration files on its local storage. Ex at 371. Aventail thus shows A method of establishing communication between one of a plurality of client computers and a central computer that maintains a plurality of authentication tables each corresponding to one of the client computers Ex at Aventail shows that if a connection request is made on a client computer that specifies a domain name or IP address matching a redirection rule, the client computer will attempt to establish a connection with a specified proxy server (e.g., the AES). Ex at 317, , , It also shows a client computer may be configured to proxy all non-locally resolved connection requests 28

33 to the AES by enabling the DNS Proxy Option on the client. Id. Aventail thus shows a process including the step of in the central computer, receiving from one of the plurality of client computers a request to establish a connection. See Ex at Aventail explains that the AES will determine if a user who has made a connection request is authorized to gain access to network resources using data it maintains about users, groups of users, policies, authentication options and other parameters. Ex at 302, 308, Aventail thus shows a method including the step of authenticating, with reference to one of the plurality of authentication tables, that the request received in step (1) is from an authorized client. Ex at Aventail shows that the AES, after determining that a user is authorized and working with Aventail Connect on the client computer, will establish a secure communication channel with the client computer. Ex at 302, 308, The network traffic sent between the client computer and the private network will be encrypted. Ex at , 352, ; See also III.C.2. Aventail also describes systems that enable a client computer running Aventail Connect to directly communicate with computers (e.g., hosts) on an internal network. See 1, above; Ex at Aventail thus shows a process including the step of responsive to a determination that the request is from an 29

34 authorized client, allocating resources to establish a virtual private link between the client and a second computer. Ex at Aventail explains that once the VPN is established with the client computer, network traffic will be sent between that client and the involved computer(s) on the private network, and that this traffic will be automatically encrypted. Ex at , 352, Aventail thus shows a process including the step of communicating between the authorized client and the second computer using the virtual private link. See Ex at Aventail anticipates claim 13 because it shows a process with every step recited in claim 13. Ex at Aventail Anticipates Claim 18 Aventail describes processes that automatically and transparently establish a VPN between a client computer and a remote network in response to a user specifying a secure destination in a connection request. Ex at Aventail also describes systems that enable a client computer running Aventail Connect to directly communicate with computers (e.g., hosts) on an internal network. See 1, above; Ex at Aventail therefore shows A method of transparently creating a virtual private network (VPN) between a client computer and a target computer. Ex at ; see id. at Aventail explains the Aventail Connect software will intercept connection requests (with a domain name or an IP address) on a client computer and evaluate 30

35 those requests. Ex at It also shows a request that contains a domain name matching a domain name in a redirection rule triggers a sequence of steps that establish a VPN between the client computer and the secure destination. Ex at 307, , Aventail thus describes a process that includes a step of generating from the client computer a Domain Name Service (DNS) request that requests an IP address corresponding to a domain name associated with the target computer. Ex at Aventail explains that redirection rules were used in its system to identify connection requests made on a client computer containing a domain name or IP address requiring secure communications. Ex at , , Redirection rules include domain names or IP addresses associated with destinations requiring secure communications. Ex at 324, A client computer running Aventail Connect could either evaluate connection requests locally, or could proxy connection requests to a proxy server (e.g., the AES) for handling. Ex at , Aventail thus describes a process including a step of of determining whether the DNS request transmitted in step (1) is requesting access to a secure web site. Ex at Aventail shows that if a domain name in a connection request matches a redirection rule, the request is flagged for special handling by replacing the domain name with a false entry (e.g., HOSTENT ). Ex at , 342,

36 352. Then, after the name resolution step, the connection request is evaluated if it contains the false entry or an IP address matching a redirection rule, it is is designated to be sent ( proxied ) to the proxy server (e.g., AES) specified in the redirection rule for that domain name or IP address. Ex at Next, the client computer opens a connection to the proxy server, and authenticates the user. Ex at If authentication is successful, the request is then sent to the proxy server, and communications will proceed, with data being sent between the client and the private network being automatically encrypted Ex at , 357. Aventail thus shows a process including the step of in response to determining that the DNS request in step (2) is requesting access to a secure target web site, automatically initiating the VPN between the client computer and the target computer. Ex at Aventail explains that a client computer may be configured to route all connection requests not matching a local domain rule to a proxy server for handling by enabling the DNS Proxy Option in the client software. Ex at 317, , , It also explains a client computer may have no local domain resolution rules as this feature is optional. Ex at This will cause the client to route all connection requests to the AES for handling (i.e., name resolution, authentication, etc.). Aventail thus shows a process where steps (2) and (3) are performed at a DNS server separate from the 32