`By:
`
`Joseph E. Palys
`Paul Hastings LLP
`875 15th Street NW
`Washington, DC 20005
`Telephone: (202) 551-1996
`Facsimile: (202) 551-0496
`E-mail: josephpalys@paulhastings.com
`
`
`
`Paper No.
`Filed: April 24, 2015
`
`Naveen Modi
`Paul Hastings LLP
`875 15th Street NW
`Washington, DC 20005
`Telephone: (202) 551-1990
`Facsimile: (202) 551-0490
`E-mail: naveenmodi@paulhastings.com
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`
`
`
`
`APPLE INC.
`Petitioner
`
`v.
`
`VIRNETX INC.
`Patent Owner
`
`
`
`
`
`
`
`Case IPR2014-00404
`Patent 7,987,2741
`
`
`
`
`
`
`
`
`
`
`Patent Owner’s Demonstrative Exhibits
`
`
`
`
`1 Case IPR2014-00484 has been joined with this case.
`
`
`
`
`
`
`Inter Partes Review of
`
`U.S. Patent No. 7,987,274
`
`Case No. IPR2014-00403
`
`Case No. IPR2014-00404
`
`Oral Hearing: April 28, 2015
`
`
`
`Instituted Grounds
`
`F
`
`- IPR20l4-00403
`
`— Claims 1, 7, 8, 10, 12, 13, 15, and 17 are anticipated
`by Provino
`
`— Claims 2-5 are obvious over Provino in View of Kosiur
`
`— Claim 18 is obvious over Provino in View of Xu
`
`- IPR2014-00404
`
`— Claims 1-4, 7, 8, 10, 12, 15, and 17 are anticipated by
`Kiuchi
`
`— Claims 1-4, 7, 8, 10, 12, 15, and 17 are obvious over
`Kiuchi and Bhatti
`
`— Claim 5 is obvious over Kiuchi, Lindblad, and Bhatti
`
`
`
`Independent Claim 1
`
`A method of accessing a secure network address, comprising:
`
`sending a query message from a first network device to a secure
`
`domain service, the query message requesting from the secure
`domain service a secure network address for a second network
`
`device;
`
`receiving at the first network device a response message from the
`secure domain name service containing the secure network
`address for the second network device; and
`
`sending an access request message from the first network device to
`the secure network address using a virtual private network
`communication link.
`
`EX. 1001, ’274 Patent. Claim 1
`
`
`
`
`
`Instituted GroundsInstituted Grounds
`
`
`
`(IPR2014-00403)(IPR2014-00403)
`
`
`
`Instituted Grounds: IPR2014-00403
`
`- 35 U.S.C. § 102
`
`— Claims 1, 7, 8, 10, 12, 13, 15, and 17 are
`
`anticipated by Provino
`
`- 35 U.S.C. § 103
`
`— Claims 2-5 are obvious over Provino in View of
`
`Kosiur
`
`— Claim 18 is obvious over Provino in View of Xu
`
`Institution Decision at 21
`
`
`
`Deficiency A: Provino fails to teach the claimed “sending a
`query message” to a “secure domain service”
`
`Deficiency B: Provino fails to teach the claimed “sending an
`access request message”
`
`Deficiency C: Provino fails to teach the claimed “tunneling”
`
`or “tunnel packeting”
`
`Deficiency D: Provino fails to teach the claimed “registered”
`limitations
`
`Deficiency E: Provino in combination with cited references
`fail to support the asserted obviousness grounds
`
`
`
`IPRZO 14-00403
`
`Provino
`
`Deficiency A
`
`
`
`Deficiency A
`
`- Provino does not disclose:
`
`sending a query message from a first network device to a secure
`domain service, the query message requesting from the secure
`domain service a secure network address for a second network
`
`device;
`
`— Part 1: The ’274 Patent disclaims conventional domain name servers
`
`like that disclosed by Provino
`
`°
`
`’274 Patent disclosure
`
`° Prosecution file history
`
`° District court
`
`— Part 2: Provino does not disclose a “secure domain service” under
`
`Petitioner’s proposed construction of the term
`
`Ex. 1001, ’274 Patent, Claim 1
`
`
`
`Deficiency A: Provino
`
`- Decision points to nameserver 32
`
`TOIF ROM
`ACCESSED
`DEVICES
`
`TO/FROM
`
`°“*'‘
`
`ISP‘S
`
`NAME
`SERVER 17
`
`fD
`
`EVICE 12(1)
`
`DEVICE 12(m)
`
`INTF 20
`
`up PRM STR 25
`
`4,
`
`I W ‘
`GENR22 r 2,
`-
`E h
`40
`KTP
`I SECURE
`
`RCVR &
`PROC 23
`
`PKT PROC
`26
`
`NTERNET —w
`
`PROVIDER
`
`iii:
`-
`42
`E
`
`1 -
`TOIFROM
`OTHER
`usrrs
`
`[E]
`In
`6 E
`‘ "
`EVlCE12(M)
`
`Ex. 1003, Fig. 1; Decision at 15; Petition at 29
`
`"T
`
`'
`
`43
`
`""
`
`1'1‘
`
`30
`
`TOIFROM
`
`ACCESSED
`DEVICES
`
`'3
`u—..
`GERVER31(5)
`
`[I
`
`1', "'7 ii
`‘-I 3‘,
`*4
`‘
`VPN NAME
`SERVER 32
`
`: VIRTUAL PRIVATE
`. NETWORK15
`l ______________ _-
`
`
`
`Deficiency A: “Secure Domain (Name) Service”
`
`‘ Patent 0wncr’s
`Construction
`
`A lookup service that
`recognizes that a query
`message is requesting a secure
`computer address, and returns
`a secure computer network
`address for a requested secure
`domain name
`
`A service that can resolve
`secure computer network
`addresses for a secure domain
`name for which a conventional
`domain name service cannot
`resolve addresses
`
`No construction
`
`Patent Owner Response at 15
`
`
`
`A Secure DNS is Not 21 Conventional DNS: Specification
`
`- The ’274 patent specification explains that the claimed “secure domain
`service” performs more than conVentiona1DNS functions
`
`Conventional Domain Name Servers (DNSS) provide a
`look-up function that returns the IP address of a requested
`computer or host. For example, when a computer user types in
`the web name “Yahoo.com,” the user’ s web browser transmits
`a request to a DNS, which converts the name into a four-part
`IP address that is returned. to the user’ s browser and then used
`
`by the browser to Contact the destination Web site.
`
`Ex. 1001, 38:54-60; Patent Owner Response at 29
`
`
`
`A Secure DNS is Not a Conventional DNS: Specification
`
`One conventional scheme that provides secure virtual pri-
`vate networks over the Internet provides the DNS server with
`the public keys of the machines that the DNS server has the
`addresses for. This allows hosts to retrieve automatically the
`public keys of a host that the host is to communicate with so
`that the host can set up a VPN without having the user enter
`the public key ofthe destination host. One implementation of
`this standard is presently being developed as part of the
`FreeS/WAN project (RFC 2535).
`
`Ex. 1001, 39:14-22; Patent Owner Response at 29
`
`
`
`A Secure DNS is Not a Conventional DNS: Specification
`
`According to certain aspects ofthe invention, a specialized
`DNS server traps DNS requests and, if the request is from a
`special type of user (e.g., one for which secure con1n1unica-
`tion services are defined), the server does not return the true IP
`address of tlie target node. but instead automatically sets up a
`virtual private network between the target. node and the user.
`
`Ex. 1001, 39:26-31; Patent Owner Response at 30
`
`
`
`A Secure DNS is Not a Conventional DNS: Specification
`
`Moreover, an entity can register several secure domain
`11an1es. with each respective secure domain name represent-
`ing a difierent priority level of access in a hierarchy of access
`levels to a secure website. For example, a securities trading
`website can provide users secure access so that a denial of
`service attack on the website will be inefi'ectual with respect
`to users subscribing to the secure website service. Different
`levels ofsubscription can be arranged based on, for example,
`an escalating fee. so that a user can select a desired level of
`guarantee for connecting to the secure securities trading web-
`site. When a user queries SDN S 3313 for the secure computer
`network address for the securities trading website, SDNS
`3313 determines the particular secure computer network
`address based on the user’s identity and the user’s subscrip-
`tion level.
`
`Ex. 1001, 47:23-37; Patent Owner Response at 17
`
`
`
`A Secure DNS is Not a Conventional DNS: Specification
`
`The grandparent of the ‘274 patent.
`
`the ’l80 patent. similarly includes
`
`einbodinients that perform more than the conventional DNS functions.
`
`For
`
`example.
`
`2603 requesting that a virtual private network be created between user computer
`
`“DNS p1'oxy 2610 transniits a message to gatekeeper
`
`2601 and secure target site 2604.” with an IP address only being retiuned after the
`
`secure conmnuiication link is set 11p.
`
`(Ex. 1025. 40:53-65: Ex. 2041 at fl 37.
`
`Monrose Decl.)
`
`“[t]lie gatekeeper would establish a VPN between the client and the requested
`
`target” before any IP address is returned.
`
`(Ex. 1025. 41:65-42:7; Ex. 2041 at ‘ 37.
`
`Monrose Decl.) Likewise. in another einbodinient. the SDNS only returns a secure
`
`URL after it has already coordinated with the VPN gatekeeper to establish a VPN.
`
`(Ex. 1025. 52:27-40: Ex. 2041 at ‘I 3738. Monrose Decl.)
`
`Patent Owner Response at 31-32
`
`
`
`A Secure DNS is Not a Conventional DNS: File History
`
`- Patent Owner disclaimed domain services that do not recognize that a
`query message is requesting a secure computer network address
`
`During the now-completed inter partes reexainiiiation of USPN 7_188_180 (“the ‘180 patent‘'’)_
`
`the grandparent of the ‘.274 patent. \'irnetX unambiguously stated:
`
`A secure domain name service is not a domain name
`
`service
`
`that
`
`resolves
`
`a domain name query that.
`
`unbeknownst
`
`to the sec1u'e domain name
`
`service.
`
`happens to be associated with a secure domain name. A
`
`secure domain name senice of the ‘ISO patent. instead.
`
`recognizes that a query message is requesting a secure
`
`computer‘ net\\='o1‘k address and performs its senices
`
`accordi11gl_\;'.
`
`(Ex. 2040 at 7. Response to Office Action in Control No. 95./001.270 (Apr. 19.
`
`2010): see also id. at 8. “the secure domain name service .
`
`.
`
`. is different from a
`
`conventional domain name service,” 11: Ex. 1001 at 47:15-51.)
`
`Patent Owner Response at 16-17; Ex. 2040 at 7 (Control No. 95/001,270)
`
`
`
`A Secure DNS is Not a Conventional DNS: District Court
`
`Vimetx repeatedly distinguishes a secure domain name service from a convemional domain
`
`name service, implying that the secure domain name service is not conventional. Further, the
`
`‘I80 Patent distingiishes between a secure domain name service and a standard domain name
`
`service. See ‘180 Patent col. 51:29-45 (distinguishing between a “secure domain name service
`
`(SDNS)°’ and a “standard domain name service (STD DNS)”).
`
`The Court construes “secure domain name service” as “:1 non—standard lookup service
`
`that recognizes that a query message is requesting a secure computer address, and returns a
`
`secure computer network address for a requested secure domain name.”
`
`Ex. 1018 at 18-19; Patent Owner Response at 17
`
`
`
`Deficiency A- Part 1
`
`The specification may “disavow [a piior an] enibodnnent." even if it “would
`
`otheiwise be covered by tl1e plain language of the claims.“ by criticizing such an
`
`4.
`I.‘
`«gr “
`.
`<
`K
`51'‘
`4
`A
`"
`
`enibodinient in the specification or repeatedly illustrating the novel features that
`
`_
`.
`.
`.
`.
`.
`are different t1'on1 that prior art ernbodnnent. In re Abb0rfD1abere.s' Care Inc. 696
`
`F.3d 1142. 1149-50 (Fed. Cir. 2004)
`
`Patent Owner Response at 27
`
`
`
`Deficiency A- Part 1
`
`— In re Abbott Diabetes Care Inc., 696 F.3d 1142, 1149-50 (Fed. Cir. 2004)
`
`Fuxtlter. an amendment
`
`to the claims to 1‘€ll1OV'€
`
`any alleged
`
`4.
`
`j‘,,‘§’ “
`.
`<
`t
`I u
`"\
`\
`
`alnbignity is not reqttired when the specification provides the reqllired disclaimer
`
`of claim scope. Abbott. 696 F.3d at 1149 (rejecting the Oft'1ce‘s a1'gun1ent that
`
`patentee had “the oppomunty a11d responslblhty to l'€ll10\'€
`
`any anlblgluty 111 cla11n
`
`tenn meaning by amending’ the claims during reexalniltation. yet failed to do so”
`
`(quoting In re Bigio. 381 F.3d 1320. 1324 (Fed. Cir. 2004))).
`
`Patent Owner Response at 28
`
`
`
`A Secure DNS is Not 21 Conventional DNS: Provino
`
`Pro\'ino’s nameserver 32 operates in precisely the same way as the
`
`conventional domain name service described and disparaged in the ‘274 patent.
`
`When nameserver 32 receives a human-readable address.
`
`it simply checks
`
`"whether it has an integer Internet address associated with the human-readable
`
`Internet address provided in the request message packet." and. if so. "generate[s] a
`
`response message packet including the integer Internet address for transmission to
`
`the firewall."
`
`(Ex. 1003. 14:39-46: Ex. 3041 at " 38. Monrose Decl.)
`
`Patent Owner Response at 32
`
`
`
`A Secure DNS is Not 21 Conventional DNS: Provino
`
`Prosecution history disclaimer confirms the View that Provinos nameserver
`
`32 is a conventional DNS that does not read on the claimed “secure domain
`
`service“ of the @774 patent. During reexamination of
`
`Patent No- 8.051.181.
`
`from which the '274 patent claims priority. VirnetX explicitly and unambiguously
`
`stated—consistent with the distinctions discussed above in the '2 74 patent
`
`specification—that P7'orino's “nameserver 32 is a conventional DNS server that
`
`does not resolve secure names.“ (See, e.g.- Ex. 3037 at 13. Rebuttal Brief in inter
`
`perms reexamination control no. 95.«"OOl.949 (Aug. 15. 2014): Ex. 2038 at 41.
`
`Appeal Bnef in inter partes reexamination control no. 95.-001.949 (Mar. 14. 3014):
`
`Ex. 3039 at 30. Patent Ovmers Response filed March 18. 3013 in inter partes
`
`reexamination control no. 95-’00l.949.)
`
`Patent Owner Response at 33
`
`
`
`Deficiency A- Part 2
`
`— Provino does not disclose a “secure domain service” under Petitioner’s
`
`proposed construction of the term
`
`Patent 0wner’s
`Construction
`A lookup service that
`recognizes that a query
`message is requesting a secure
`computer address, and returns
`a secure computer network
`address for a requested secure
`domain name
`
`No construction
`
`A service that can resolve
`secure computer network
`addresses for a secure domain
`name for which a conventional
`domain name service camiot
`resolve addresses
`
`Patent Owner Response at 15
`
`
`
`Nameserver 32 is 21 Conventional DNS Under Apple’s Construction
`
`— That a DNS can resolve a domain name that another DNS
`
`cannot does not make it a “secure domain service”
`
`Moreover. nameserver 32 behaves just like nameserver 17. which Petitioners
`
`concede is a conventional DNS.
`
`(See Pet. at 27.) VVhen nameserver 17 receives a
`
`human-readable address.
`
`it simply checks whether it “has an integer Internet
`
`address associated with the human—readable Internet address [and. if so.] provide-[s]
`
`the integer Internet address." (Ex. 1003. 1324346: Ex. 2041 at ‘ 40. Monrose
`
`Decl.) Likewise. when nameserver 32 receives a human-readable address.
`
`it
`
`simply checks "whether it has an integer Internet address associated with the
`
`h1unan—readable Internet address provided in the request message packet." and. if
`
`so. “generate[s] a response message packet including the integer Internet address
`
`for transmission to the firewall." (Ex. 1003- 14:39-46: Ex. 2041 at '7 40. Monrose
`
`Decl.)
`
`Patent Owner Response at 35-36
`
`
`
`Nameserver 32 is 21 Conventional DNS Under Apple’s Construction
`
`Nameserver 17 and nameserver 32 also operate in the same manner when
`
`they do not have an integer Internet address associated with a human-readable
`
`Internet address provided in a request. If “nameserver 17 does not have a integer
`
`Internet address associated with the human-readable Internet address. it (that is, the
`
`nameserver 17) will provide a response message packet so indicating to device
`
`12(n1)." (Ex. 1003, 13:54-58: Ex. 2041 at 1} 41, Monrose Decl.) Likewise. “if the
`
`nameseiver 32 does not have an integer Internet address associated with the
`
`hun1an—readable Internet address provided by the device l2(m) in the request
`
`message packet, it (that is, nameserver 33) can so indicate in the response message
`
`packet generated thereby.” (Ex. 1003, 15:31-35: Ex. 2041 at 1[ 41. Monrose Decl.)
`
`Patent Owner Response at 36
`
`
`
`IPRZO 14-00403
`
`Provino
`
`Deficiency B
`
`25
`
`
`
`Deficiency B
`
`- Provino does not disclose:
`
`sending an access request message from the first network device to the
`secure network address using a virtual private netwo1:k communication
`link.
`
`
`
`Deficiency B (“Access Request Message”)
`
`Patent Owner's Proposed
`Consmmfion
`
`No construction necessary;
`plain and ordinary meaning
`
`No construction proposed
`
`A signal in a packet or other
`message format that signifies
`that the first network device
`
`seeks communication,
`
`information, or services, with
`
`a second network device
`
`associated with the secure
`
`network address
`
`Patent Owner Response at 23
`
`
`
`Deficiency B (“Access Request Message”)
`
`-
`
`Institution Decision points to ProVino’s request to set-up
`tunnel
`
`On this record. according to the foregoing claim construction discussion and
`
`discussion of Provino. an "access request message.“ as claim 1 recites. reads
`
`on P1‘o\'ino‘s message packets that either essentially request the set-11p for an
`
`encrypted secure tunnel to server.-"cor11puter 3 1( s). or thereafter. request
`
`encrypted information or processes from sen'e1‘..-"'computer 3 1 (s) (or other
`
`similar devices l2(m‘) or 13).
`
`Institution Decision at 17
`
`
`
`Deficiency B (“Access Request Message”)
`
`° Claim 1 requires “sending an access request message from
`the first network device to the secure network address”
`
`The Board. unlike Petitioners- alternatively relies on Provinois alleged
`
`disclosure of “message packets that
`
`.
`
`.
`
`. essentially request the set-up for an
`
`encrypted secure tunnel to serverfconiputer 3l(s)" for the “access request message"
`
`feature of claim 1.
`
`(Decision at 17.) However. what Provino discloses is that
`
`“device l3(m) .
`
`.
`
`. generates a message packet for transfer through the ISP 11 and
`
`Internet 14 to the firewall 30 requesting establishment of a secure tunnel between
`
`the device l2(m) and firewall 30."
`
`(Ex. 1003 at 9:46-52: Ex. 2041 at 11 43.
`
`Monrose Decl.)
`
`Patent Owner Response at 39
`
`
`
`Deficiency B (“Access Request Message”)
`
`Institution Decision points to message packets
`between device 12(m) and device 13
`
`Device 12(m) also must have “the required permissions to request [services
`
`from or access to] .
`
`.
`
`. device 13.“ id. at 6:67-72. xvhich Provino explains
`
`either is a VPN or is a computer device similar to device l2(m) or 12(m‘)
`
`within a VPN. Id. at 5:47-—6:63. 8:58-62.
`
`On this record. according to the foregoing claim construction discussion and
`
`discussion of Provino. an “access request message." as claim 1 recites. reads
`
`on Provino‘s message packets that either essentially request the set-up for an
`
`encrypted secure tunnel to seiver.-’computer 31(s). or thereafter. request
`
`encrypted information or processes fi‘om seiver..v"computer 3 1 (s) (or other
`
`similar devices 12(m') or 13).
`
`Institution Decision at 16-17
`
`
`
`Deficiency B (“Access Request Message”)
`
`Likewise. Petitioners
`
`expert—whose substantive findings were never challenged during his deposition-
`
`similarly understood that “requests sent to server 31(5) by deuce 12(m) may be
`
`requests for information stored at the server 31(5)." Ex. 1011 '7 40: see Ex. 1090
`
`at 42:12-43:10 (discussing Ex. 1003 at 6: 19-28).
`
`In particular. Pronno describes that the server 31(5) may be a “storage server“ that provides
`
`information that is requested by a client. See Ex. 1003. 6:19-50. As a consequence, the requests
`
`sent to server 31(5) by device 12(m) may be requests for information stored at the server 31(5).
`
`Petiti0ner’s Reply at 11; EX. 1011, $1 40
`
`
`
`IPRZO 14-00403
`
`Provino
`
`Deficiency C
`
`32
`
`
`
`Deficiency C: Claims 12 and 13
`
`12. The method according to claim 1, further including using tunneling
`over the Virtual private network communication link.
`
`13. The method according to claim 1, fiirther including using tunnel
`packeting over the Virtual private network communication link.
`
`Ex. 1001, Claims 12 and 13
`
`
`
`“Tunnel Packeting”
`
`Patent sPr,op,osed
`Construction.
`Fonning a packet to be
`transmitted that contains data
`structured in one protocol
`format within the format of
`another rotocol
`
`Apple’s Proposed
`Conslmction
`Encapsulating a f1rst packet of Placing data or information in
`a first protocol in a second
`one protocol format (or packet
`packet of a second protocol
`portion), into another protocol
`format (or portion) of a packet
`
`Patent Owner Response at 18
`
`
`
`Deficiency C: “Tunnel Packeting” — Decision
`
`Based on the claim construction discussion of “tu1melpacketing." Pro\'ino‘s
`
`placement of a device Internet address inside the data or other portion of a
`
`packet that is 11ot the normal address portion (e. g. header) for that packet.
`
`reasonably constitutes t1n1nel packeting. On this record. Petitioner
`
`sufficiently establishes that Provino‘s system reads on claims 12 a11d 13. See
`
`Pet. 41-42 (citations omitted).
`
`Institution Decision at 18
`
`
`
`Deficiency C: “Tunnel Packeting” — Provino
`
`However- the Decision has not alleged that the integer Internet address is
`
`ever actually placed fiom "one protocol format (or packet portion)“ into “another
`
`protocol portion (or portion) of a packet-" as required by the Board's construction.
`
`Nor does Provino disclose whether an address is placed from “one protocol format
`
`(or packet portion)" into "another protocol portion (or portion) of a packet." (Ex.
`
`2041 at 11 47, Monrose Decl.) Simply placing the integer Internet address inside
`
`the data portion of a packet does not necessitate a change in protocol format from
`
`“one protocol" to "another protocol." (Ex. 2041 at
`
`47, Monrose Decl.)
`
`Patent Owner Response at 42
`
`
`
`IPRZO 14-00403
`
`Provino
`
`Deficiency D
`
`37
`
`
`
`Deficiency D: Claim 17
`
`17. The method according to claim 1, wherein the secure network
`address is registered with the secure domain service prior to the step of
`
`sending a query message to a secure domain service.
`
`Ex. 1001, Claim 17
`
`
`
`Deficiency D: Claim 17
`
`The Decision contends that Provinois integer Internet address is registered
`
`before what it claims is Provino"s “access request messaged’ (Decision at 17,) But
`
`what claim 17 requires is that the secure network address be registered before the
`
`step of sending a guegg message, not the step of sending an access request
`
`message. Even assuming the Decision’s allegations are true. claim 17 is not met.
`
`Patent Owner Response at 43
`
`
`
`Deficiency D: Provino
`
`According to the Decision “namesener 32 in Provino provides the integer
`
`Internet address by associating it with a human-readable Internet address." and
`
`“Pr-at-ino‘s query message for secure information or services .
`
`.
`
`. occurs afier the
`
`51."2'2Tc7:TT3'é‘» é’-J.tI:Io.‘f_J}'*..1‘c"Ir.:-”_-1 was created in the namesen'er"' (Decision at 19.)
`
`Patent Owner Response at 43
`
`
`
`Deficiency D: Provino
`
`The Decisions treatment of claim 17 is also incorrect because it relies on an
`
`allegedly “imp1ied" teaching by Provino that is not necessarily. or even likely,
`
`present. This is an inherent}; argument that is unsupported by the evidence- The
`
`Decision has not demonstrated that the nameserver 32 would operate in the manner
`
`it describes. See Robertsorr. 169 F.3d at 745. For example, nameserver 32 could
`
`request that a network address of server 31(5) be registered after receiving a
`
`request for the network address from device l2(m).
`
`(Ex. 2041 at " 48. Monrose
`
`Decl.)
`
`Patent Owner Response at 44
`
`
`
`IPRZO 14-00403
`
`Provino
`
`Deficiency E
`
`42
`
`
`
`Instituted Grounds: IPR2014-00403
`
`:1 “L”
`
`as +.;:
`
`1: ‘.7:
`
`I
`
`4
`
`- 35 U.S.iC.§
`
`’
`
`03
`
`s 1 iii
`
`— Claims 2-5 are obvious over Provino in View of
`
`Kosiur
`
`— Claim 18 is obvious over Provino in View of Xu
`
`Institution Decision at 21
`
`
`
`The ’274 Patent: Claims 2-5
`
`2. The method according to claim 1, further including supporting a
`
`plurality of services over the virtual private network communication
`link.
`
`3. The method according to claim 2, wherein the plurality of services
`comprises a plurality of communication protocols, a plurality of
`
`application programs, multiple sessions, or any combination thereof.
`
`4. The method according to claim 3, wherein the plurality of
`
`application programs comprises video conferencing, e-mail, a word
`
`processing program, telephony or any combination thereof.
`
`5. The method according to claim 2, wherein the plurality of services
`
`comprises audio, video, or any combination thereof.
`
`Ex. 1001, Claims 2-5
`
`
`
`Claims 2-5 — Kosiur
`
`Kosiur discusses videconferencing in its "Looking Ahead" section when
`
`explaining that- "in the future-" “[n]etwork performance over VPNS will also
`
`improve. enabling VPN links to be used for .
`
`.
`
`. videoconferencing." (Ex. 1006 at
`
`256: Ex. 2041 at ‘ 51. Monrose Decl.) Kosiur does not explain how such
`
`iniproveinents of network performance over VPNs would be achieved to enable
`
`videoconferencing.
`
`(Ex. 2.041 at "1 51. Monrose Decl-)
`
`Indeed, while Kosiur
`
`explains that "[s]ecure videoconferencing is another application of interest."
`
`Kosiur admits that “this application may require even more constraints on
`
`bandwidth and quality of service." and does not describe how such constraints
`
`could be addressed. (Ex. 1006 at 264: Ex. 2041 at 11 51- Monrose Decl.)
`
`Patent Owner Response at 45-46
`
`
`
`
`
`Instituted GroundsInstituted Grounds
`
`
`
`(IPR2014-00404)(IPR2014-00404)
`
`
`
`4646
`
`
`
`Instituted Grounds: IPR2014-00404
`
`- 35 U.S.C. § 102
`
`— Claims 1-4, 7, 8, 10, 12, 15, and 17 are anticipated
`by Kiuchi
`
`- 35 U.S.C. § 103
`
`— Claims 1-4, 7, 8, 10, 12, 15, and 17 are obvious
`
`over Kiuchi in View of Bhatti
`
`— Claim 5 is obvious over Kiuchi in View of Bhatti
`
`and Lindblad
`
`Institution Decision at 19
`
`
`
`Deficiency A: Kiuchi fails to teach the claimed “secure
`network address” and “second device” features
`
`Deficiency B: Kiuchi fails to teach the claimed “sending an
`
`access request message”
`
`Deficiency C: Kiuchi fails to teach the claimed “client
`
`computer”
`
`Deficiency D: Kiuchi and Bhatti do not disclose the claimed
`“secure network address” and “second device”
`
`features
`
`Deficiency E: Kiuchi and Bhatti do not disclose the claimed
`“sending an access request message”
`
`
`
`IPRZO 14-00404
`
`Kiuchi
`
`Deficiency A
`
`49
`
`
`
`Deficiency A: Secure Network Address / Second Network Device
`
`A method of accessing a secure network address, comprising:
`
`sending a query message from a first network device to a secure
`domain service, the query message requesting from the secure
`domain service a secure network address for a second network
`
`device;
`
`receiving at the first network device a response message from the
`
`secure domain name service containing the secure network
`
`address for the second network device; and
`
`sending an access request message from the first network device to
`
`the secure network address using a virtual private network
`communication link.
`
`Ex. 1001, Claim 1
`
`
`
`Client-
`
`Side
`
`Proxy
`O H
`
`Firewall
`
`C-HTTP Secure
`
`Name Service
`
`(:55 p 68,4 2(2))
`
`Standard/Public
`DNS-
`
`(Diagram 1)
`
`One or More
`
`Origin Servers
`
`Petition at 22
`
`
`
`The Decision’s Mapping:
`Secure Network Address and Second Network Device
`
`Clalmfllement
`
`Secure Network Address Second Network Device
`
`the query message
`
`Server-side proxy’s 1P
`
`Server-side proxy
`
`requesting from the
`
`address (Decision at 12)
`
`(Decision at 12)
`
`secure domain service a
`
`secure network address
`
`for a second network
`
`device
`
`a response message .
`
`.
`
`.
`
`Ilost's IP address
`
`llost (Decision at 13)
`
`containing the secure
`
`(Decision at 13)
`
`network address for the
`
`second network device
`
`sending an access request
`
`I-lost’s IP address
`
`Server-side proxy
`
`message from the first
`
`(Decision at 13)
`
`(Decision at 13, 14)
`
`network device to the
`
`OR
`
`secure network address
`
`Servenside proxy‘s 1P
`
`using a virtual private
`
`address (Decision at 14)
`
`network communication
`
`link
`
`Patent Owner Response at 31-32
`
`
`
`The Host Server is the Origin Server: Kiuehi
`
`1) Connection of a client to a client-side proxy
`
`When one of these resource
`
`names nitli a connection ID. for example,
`"http://server.in_current.eonnectiom’samp1c.httrtl—@I.—6Ld
`DfldfcZLj8V!i" in Figurc (b). is selected and requested by
`an end-user, the client-side prom,’ takes off the connection
`ID and forwards the stripped the original resource name
`to the server in its request as described in Figure (C).
`
`2) Lookup of server-side proxy infonnatton (Appendix 3.
`ztb)
`
`A client—5ide proxy asks the C-HTTP name server
`whether it can communicate with the host specified in a
`given URL. If the name sewer confirms that the query is
`
`Ex. 1004 at 65, § 2.3(1)-(2), Kiuchi
`
`
`
`The Host Server is the Origin Server: Petitioner
`
`Petitioners acknowledge that the origin sewer is the host a11d that the server-
`
`side proxy and host are different devices. For instance. petitioners state that each
`
`origin server has a hostnaine that is registered with the C-HTTP name sewer (Pet.
`
`at 26) and that
`
`the origin sen'er's hostnanre may be different than the origin
`
`se1\'er‘s D.\IS name (Pet. at 24-25). Citing to Kiuchi is teaching that “the host [is]
`
`specified in a given URL.“ petitioners
`
`explain that
`
`the
`
`"[t]l1e
`
`l1ost11a111e
`
`‘sei\'er.in.cun‘ent.co1mection'
`
`included in the URL“ is
`
`the origin se1\‘er‘s
`
`liostnanie.
`
`(Id. at 24-25.) Thus. the 110st is the origin sen'er. which petitioners
`
`depict and describe as being different from the sen'er-side proxy.
`
`(See Pet. at 22-
`
`31. Diagrams 1-7 depicting the “Server-Side Proxy 011 Firewall“ as different and
`
`separate from the "One or More Origin Sen'ers." 22. stating “one or 111ore origin
`
`servers [are] associated with the sen-‘er-side proxy": Ex. 1011 at T 28.)
`
`Patent Owner Response at 34
`
`
`
`IPRZO 14-00404
`
`Kiuchi
`
`Deficiency B
`
`55
`
`
`
`Deficiency B
`
`- Kiuchi does not disclose:
`
`sending an access request message from the first network device to the
`secure network address using a virtual private network communication
`link.
`
`Part 1: Kiuchi’s HTTP/1.0 Message is not sent to the alleged secure
`computer address
`
`Part 2: Kiuchi’s HTTP/1.0 Message is not an “access request
`
`message”
`
`Part 3: Kiuchi’s HTTP/1.0 Message is not sent using a Virtual private
`network communication link
`
`Part 4: Kiuchi’s step (3) request for connection is not sent using a
`Virtual private network communication link
`
`
`
`Deficiency B: Part 1 - Decision
`
`Hence. Kiuchi discloses sending an "access request message" (i.e.. an “HTTP.-"'1 .0
`
`request”) from the fn'st network device (i.e.. the "client-side proxy“) to the secure
`
`network address (i.e.. the IP address corresponding to the host) using a virtual
`
`private network co11n11unication link. i.e.. the HTTP«"l .0 request signifies that the
`
`client-side proxy (i.e.. “first network device“) seeks conmiunication with the
`
`“sen‘er-side proxy” (i.e.. a second network device associated with the secure
`
`network address).
`
`Institution Decision at 13
`
`
`
`Deficiency B: Part 1 - HTTP/ 1.0 Message Is Not Sent
`From a First Network Device to a Secure Network Address
`
`As shown in Kiuchfs Fig.
`
`(c)(l) and (c)(2),
`
`reproduced below,
`
`the
`
`HTTP.v'l.0 request is a “GET” request that is sent “from the user agent” to the
`
`client-side proxy‘
`
`c. H11?-‘L0 request from the user agent 1!) and
`H‘. IP; I .0 request encrypted and wrapped In C-HTTP
`request dispatched by the client side armry (2)
`
`(U
`GET ‘M151 .'Iservetln.cunern.(unm:imn.
`sample hlml-ull-6zdDfldfcZl.;8\»"I'
`H"TP_-1.C~-- CR
`LF -
`
`(2:
`GET ‘hum: .*sen/cr.tn.current.conne:non.
`SIflIp|t.htI'nl'
`HTTP,» I .-3-.-CR»
`
`(Ex. 1004 at 66, Fig. (c), § 23(6).) In Fig. (c)('2)_, the client-side proxy receives the
`
`HTTP.-"l.0 request and initiates and dispatches a new C-HTTP request.
`
`(See id. at
`
`Fig. (c).) Thus, what is sent from the client—side proxy is not an HTI'P.-'l.0 request,
`
`but a C-HTTP request. The HTTP.-’1.0 request is neither sent by the alleged first
`
`network device (the client-side proxy), nor is it received at the alleged secure
`
`network address (host sen-'er’s IP address or the server-side proxy’s IP address).
`
`Patent Owner Response at 37
`
`
`
`Deficiency B: Part 2
`
`HTTP/1.0 Message Is Not an Access Request Message
`
`Because the HTTP.»"1.0 message seeks
`
`a11 HTML resotlrce from the
`
`origin/liost sen'e1'. it is not seeking any “conintunication. infonnation. or senices“
`
`from the sen'e1‘-side proxy.
`
`(Ex. 1004 at 65-66. § 2.3(l). Fig. (C): Ex. 2041 at T 45.
`
`Monrose Decl.) Unlike the earlier messages sent between the client-side and
`
`sen'e1‘-side proxies to establish the C-HTTP connection. the user agent sending the
`
`HTTP.-"'1.0 request is not seeking coimnunication with the seiver-side proxy. but
`
`with the oiigin sen'ei' to which the HTTP/1.0 message is addressed.
`
`(Ex. 2041 at
`
`T 45. Monrose Decl.)
`
`Patent Owner Response at 38
`
`
`
`Deficiency B: Part 3 - HTTP/ 1.0 Message Is
`
`Not Sent Using a Virtual Private Network Communication Link
`
`Properly construed, a virtual private network communication link requires a
`
`VPN. And a VPN necessarily requires a “network” and "direct conununicationf’
`
`(See supra Sections II-A.2-3.) The sending of Kit.-chi’: HTTP»'1.0 message meets
`
`neither of these requirements.
`
`A communication path
`between computers in a virtual
`private network
`
`Any communication link
`between two end points in a
`virtual private network
`
`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
`
`Patent Owner Response at 39, 4
`
`
`
`Deficiency B: Part 3 - A VPN
`
`Communication Link Exists Only in a VPN: Specification
`
`As explained in the '27-1 patent. a VPN communication link does not exist
`
`outside of a virtual private network. When a secure domain name service (SD