Filed on behalf of: VirnetX Inc.
`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-00403
`Patent 7,987,2741
`
`
`
`
`
`
`
`
`
`
`Patent Owner’s Demonstrative Exhibits
`
`
`
`
`1 Case IPR2014-00483 has been joined with this case.
`
`
`
`
`
`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-00403
`Patent 7,987,2741
`
`
`
`
`
`
`
`
`
`
`Patent Owner’s Demonstrative Exhibits
`
`
`
`
`1 Case IPR2014-00483 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
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
