Trials@uspto.gov
`571-272-7822
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`MICROSOFT CORP.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`____________
`
`Case IPR2014-00403
`Patent 7,987,274 B2
`____________
`
`Before MICHAEL P. TIERNEY, KARL D. EASTHOM, and STEPHEN C.
`SIU, Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`
`Paper 13
`Date: July 31, 2014
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`
`571-272-7822
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`MICROSOFT CORP.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`____________
`
`Case IPR2014-00403
`Patent 7,987,274 B2
`____________
`
`Before MICHAEL P. TIERNEY, KARL D. EASTHOM, and STEPHEN C.
`SIU, Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`
`Paper 13
`Date: July 31, 2014
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`I. BACKGROUND
`
`
`
`
`
`A. Introduction
`Petitioner, Microsoft Corp., filed a revised Petition requesting inter
`partes review of claims 1–5, 7, 8, 10, 12, 13, 15, 17, and 18 of U.S. Patent
`No. 7,987,274 B2 (“the ’274 Patent,” Ex. 1001) pursuant to 35 U.S.C.
`§§ 311–319. Paper 4 (“Pet.”). Patent Owner, VirnetX, Inc., filed a
`Preliminary Response. Paper 9 (“Prelim. Resp.”).
`We have jurisdiction under 35 U.S.C. § 314. The standard for
`instituting inter partes review is set forth in 35 U.S.C. § 314 (a):
`THRESHOLD.—The Director may not authorize an inter
`partes review to be instituted unless the Director
`determines that the information presented in the petition
`filed under section 311 and any response filed under
`section 313 shows that there is a reasonable likelihood
`that the petitioner would prevail with respect to at least 1
`of the claims challenged in the petition.
`We determine, based on the record, that Petitioner has demonstrated,
`under 35 U.S.C. § 314(a), that there is a reasonable likelihood of
`unpatentability with respect to all of the challenged claims, claims 1–5, 7, 8,
`10, 12, 13, 15, 17, and 18.
`Petitioner relies on the following prior art references:
`U.S. Patent No. 6,557,037 B1 (Apr. 29, 2003) (“Provino”) (Ex. 1003);
`
`U.S. Patent No. 6,151,628 (Nov. 21, 2000) (“Xu”) (Ex. 1007); and
`
`Dave Kosiur, Building and Managing Virtual Private Networks (Sept.
`1, 1998) (“Kosiur”) (Ex. 1006).
`
`Pet. ii.
`Petitioner contends that the challenged claims are unpatentable under
`35 U.S.C. §§ 102 and 103 based on the following grounds.
`2
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`
`
`
`
`
`
`Reference(s)
`
`Basis
`
`Claims challenged
`
`§ 102(e) 1, 7, 8, 10, 12, 13, 15, and 17
`Provino
`Provino and Kosiur § 103(a) 2–5
`Provino and Xu
`§ 103(a) 18
`
`
`See Pet. 4.
`
`B. The ’274 Patent
`The ’274 Patent discloses secure networks. To provide a secure
`network, the ’274 Patent system modifies conventional Domain Name
`Servers, which the ’274 Patent describes as follows:
`Conventional Domain Name Servers (DNSs) provide a
`look-up function that returns the IP [Internet Protocol] 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.
`The ’274 Patent describes providing a top-level secure domain
`name:
`
`In one embodiment, software module 3309 automatically
`replaces the top-level domain name for server 3304 within
`browser 3406 with a secure top-level domain name for server
`computer 3304 . . . .
`Because the secure top-level domain name is a non-
`standard domain name, a query to a standard domain name
`service (DNS) will return a message indicating that the
`universal resource locator (URL) is unknown. According to the
`invention, software module 3409 contains the URL for
`querying a secure domain name service (SDNS) for obtaining
`the URL for a secure top-level domain name. . . .
`3
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`
`
`
`
`
`
`. . . .
`
`SDNS 3313 contains a cross-reference database of secure
`domain names and corresponding secure network addresses.
`That is, for each secure domain name, SDNS 3313 stores a
`computer network address corresponding to the secure domain
`name. . . . Returning to FIG. 34, in step 3410, SDNS 3313
`returns a secure URL to software module 3309 . . . .
`. . . .
`
`
`
`At step 3411, software module 3309 accesses secure
`server 3320 through VPN communication link 3321 . . . .
`
`Id. at 46:31–47:67.
`
`In addition to providing a secure domain name, the ’274 Patent
`describes creating a secure communication link in the form of a virtual
`private network (“VPN”) link. One preferable “VPN communication link
`can be based on a technique of inserting a source and destination IP address
`pair into each data packet that is selected according to a pseudo-random
`sequence.” Id. at 46:64–67. The ’274 Patent refers to this technique and
`similar techniques as “information hopping technique[s].” Id. at 47:13–14.
`The ’274 Patent states that “[f]urther communication . . . occurs via
`the VPN, e.g., using a ‘hopping’ regime as discussed above.” Id. at 48:4–6.
`The ’274 Patent states that by clicking a “‘go secure’ hyperlink[,] [t]he user
`does not need to enter any user identification information, passwords or
`encryption keys for establishing a secure communication link.” Id. at 46:22–
`25. A secure icon indicates a “secure VPN communication link.” Id. at
`48:1–4.
`
`
`
`
`4
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`
`According to Patent Owner, the claims are directed to some of the
`embodiments represented by Figure 33 (see Prelim. Resp. 11), reproduced
`below:
`
`
`
`
`
`Figure 33 depicts an embodiment in which computer 3301 connects to
`secure server 3320 over Internet 3302, via the network that includes secure
`portal 3310.
`Claim 1, the sole independent claim, follows:
`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;
`
`5
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`
`
`
`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.
`
`C. Related District Court Proceeding and Inter Partes Review Requests
`Patent Owner asserted the ’274 Patent in VirnetX Inc. v. Microsoft
`Corp., No. 6:13-cv-00351-LED (E.D. Tex. filed 2013). See Pet. 1–2.
`Petitioner also challenges the ’274 Patent in Case IPR2014-00404 and
`challenges a related patent in Cases IPR2014-00401 and IPR2014-00405.
`D. Claim Interpretation
`Consistent with the statute and the legislative history of the Leahy-
`Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284, 329 (Sept.
`16, 2011) (“AIA”), the Board interprets claim terms by applying the
`broadest reasonable interpretation in the context of the specification in
`which the claims appears. 37 C.F.R. § 42.100(b); see Office Patent Trial
`Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012).
`Under the broadest reasonable interpretation standard, claim terms are
`given their ordinary and customary meaning, as would be understood by one
`of ordinary skill in the art in the context of the entire disclosure. In re
`Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). Any special
`definition for a claim term must be set forth in the specification with
`reasonable clarity, deliberateness, and precision. In re Paulsen, 30 F.3d
`1475, 1480 (Fed. Cir. 1994). Claim terms typically do not include
`limitations from embodiments described in a patent specification if the claim
`
`6
`
`
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`language is broader than the embodiment. See In re Van Geuns, 988 F.2d
`1181, 1184 (Fed. Cir. 1993).
`1. Access Request Message
`The parties do not propose a construction for this term, and it appears
`only in the claims of the ’274 Patent. Claim 1 recites “sending an access
`request message from the first network device to the secure network address
`using a virtual private network communication link.” This step appears after
`the first-listed step of “sending a query message” for a “secure network
`address.” In other words, “sending an access request message” reasonably
`appears to be a query to communicate for information, services, or
`otherwise, which may occur after an initial step of sending a query for
`address information.
`The ’274 Patent supports this construction, for example, disclosing
`that “software module 3309 accesses secure server 3320 through VPN
`communication link 3321” at step 3411. Ex. 1001, 47:66–67. Here, access
`refers to further communication using a hopping regime with the desired
`server, for example, a securities trading website, server 3320. See id. at
`47:26–29, 38–41; 48:4–6.
`Patent Owner’s citation implicitly refers to what appears to be a step
`that occurs relatively early in the disclosed process, step 3409, cited in a
`related portion of the ’274 Patent as an example of an access request
`message. Prelim. Resp. 10 (citing Ex. 1001, 47:37–51). In that step, “SDNS
`3313 accesses VPN gatekeeper 3314 for establishing a VPN communication
`link.” Ex. 1001, 47:38–39. It is not clear how that passage relates to the
`recited access request message, which the first network device (i.e., not
`
`7
`
`
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`SDNS 1313) sends to the secure network address (i.e., not to gatekeeper
`3314) using a VPN communication link.
`Under the broadest reasonable construction, in light of the claim
`language and disclosure, the “access request message” includes 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.
`2. VPN Communication Link
`As noted above, claim 1 recites the term “access request message” in
`terms of the VPN communication link, thereby, to a certain extent,
`informing the meaning of the latter term based on our construction of the
`“access request message.” Claim 11 depends from claim 1 and, although not
`challenged here, it further informs that “initiating the virtual private network
`communication link [occurs] after the access request message,” at least in
`some embodiments. Ex. 1001, claim 11 (emphasis added). If the VPN
`communication link is initiated after the access request message in claims 1
`and 11, then in claim 1, using a virtual private network communication link
`reasonably embraces using a link that merely connects to a virtual private
`network. Otherwise, it is not clear how the method of claim 1 uses a VPN
`communication link that has not been “initiated.”
`A VPN communication link appears to employ different levels of
`security, ranging from employing hopping techniques on VPN
`communication link 3319 for initial access to, for example, secure portal
`3310 and VPN gatekeeper 3314, then to authentication for that access, and
`then later, to other secure connections established by the gatekeeper, which
`securely connects device 3301 to server 3320 over the Internet, thereby
`
`8
`
`
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`establishing VPN communications between PC 3301 and server 3320, even
`though neither device is “behind” VPN gatekeeper 3314 or secure portal
`3310. See Ex. 1001, 46:58–48:4; Figs. 33, 34. The ’274 Patent states that
`“[o]ther types of VPNs can alternatively be used.” Id. at 47:11.
`The parties appear to agree that a VPN communication link is a
`communication path or link between two devices in a VPN. See Prelim.
`Resp. 17–18 (discussing agreement). The parties also appear to agree that a
`VPN requires encryption. See Prelim. Resp. 13 (discussing agreement).
`Nonetheless, as explained above, the ’274 Patent employs various levels of
`security that do not require encryption, for example, information or address
`hopping, as noted above.
`On this record, the broadest reasonable interpretation of a VPN
`communication link is a transmission path between two devices that restricts
`access to data, addresses, or other information on the path, generally using
`obfuscation methods to hide information on the path, including, but not
`limited to, one or more of authentication, encryption, or address hopping.1
`3. Secure Network Address
`As noted above, claim 1 recites “sending an access request message
`from the first network device to the secure network address using a virtual
`private network communication link.” The parties agree that a “secure
`network address” at least requires “authorization for access.” See Prelim.
`Resp. 20; Pet. 6. For purposes of this Decision, a “secure network address”
`is an address that requires authorization for access.
`
`1 The Board applied a similar definition in Apple Inc. v. VirnetX, Case
`IPR2014-00237, Paper 15, slip op. at 9–11 (PTAB May 14, 2014) and Apple
`Inc. v. VirnetX, Case IPR2014-00238 (PTAB May 15, 2014), which
`challenge related VirnetX patents.
`
`9
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`
`
`
`The parties also appear to agree that the secure network address must
`be associated with a computer and a virtual private network. Prelim. Resp.
`21; Pet. 6. The term, “secure network address,” apart from the qualifying
`phrase, “using a virtual private network communication link,” does not
`necessarily require a computer “capable of virtual private network
`communications,” as Patent Owner urges, or “configured to be accessed
`through a virtual private network,” as Petitioner urges. See Prelim. Resp.
`21; Pet. 6. The “virtual private network communication link” phrase does
`appear to qualify, to some extent, the secure network address. Nevertheless,
`at this stage, no need exists to resolve any dispute over “capable” or
`“configured.”
`4. Tunnel Packeting
`Claim 13 depends from claim 1 and recites “using tunnel packeting
`over the [VPN] communication link.” Petitioner argues that “tunnel
`packeting” should be broad enough to encompass “encapsulating a first
`packet of a first protocol in a second packet of a second protocol.” Pet. 14–
`15. Petitioner cites a portion of the ’274 Patent that describes an
`embodiment that “tunnels the unencrypted, unprotected communication
`packets through a new protocol.” Pet. 14. (citing Ex. 1001, 49:31–34.)
`Petitioner’s declarant, Dr. Guerin, notes that it was well-known that
`“tunneling generally [was understood] to include implementations at
`different layers.” Ex. 1011 ¶ 26.
`Patent Owner contends that a customary definition of “tunneling,”
`which apparently includes tunnel packeting, is “transmitting data structured
`in one protocol format within the format of another protocol.” Prelim. Resp.
`29 (citing Ex. 2026, 7.) Patent Owner explains that in one example of the
`
`10
`
`
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`’274 Patent, “data structured in a first protocol format is placed into the
`payload of a packet in a second protocol format.” Prelim. Resp. 29
`(discussing Ex. 1001, 50:44–52). In context, according to Patent Owner’s
`apparent position, a first protocol format includes a part of a packet or frame,
`such as a header (e.g., an address), and a second protocol format includes
`another part of a packet or frame, such as the payload (e.g., the data). See
`Prelim. Resp. 29 & n. 8.
`Patent Owner characterizes the dispute about the term as follows:
`“Under [Petitioner’s] construction, the payload of a first protocol is stripped
`out and is encapsulated in a second protocol. The patent, however, teaches
`that a first protocol’s entire packet (not just its payload) can become the
`payload of a second protocol’s packet.” Prelim. Resp. 29–30.
`On this record, the broadest reasonable interpretation of the term does
`not limit it to what “can” occur in a specific embodiment. The term
`reasonably supports encapsulating one packet portion or an entire packet
`inside of another packet. Therefore, for purposes of this decision, “tunnel
`packeting” means placing data or information in one protocol format (or
`packet portion), into another protocol format (or portion) of a packet.
`5. Remaining Claim Terms
`The parties do not disagree materially about other claim terms
`involved in this proceeding. It is not necessary to construe explicitly other
`claim terms at this juncture of the proceeding.
`
`II. ANALYSIS
`
`A. Preliminary Arguments
`Patent Owner maintains that the Petition is defective because 1) it
`presents redundant grounds and 2) the Petition lacks requisite statutory and
`
`11
`
`
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`rule specificity about where claimed elements are found in the prior art; and
`3) the Petition is redundant to a related petition. See Prelim. Resp. 1–9.
`Notwithstanding Patent Owner’s arguments, even if one petition may
`be considered redundant to another, or a petition internally presents
`redundant grounds, the Board has discretion to go forward or not go forward
`on redundant grounds in the interests of expediency. See 37 C.F.R. §§
`42.5(a), 42.108(a); 35 U.S.C. § 315(d) (discretion to consider current
`proceedings before the office). Notwithstanding Patent Owner’s other
`assertions, the record does not show that the Petition is statutorily or by rule
`deficient for a lack of clarity or particularity. The Board may not institute
`unless there are “[s]ufficient grounds.” See 37 C.F.R. § 42.108(c). We
`determine, based on the record, that Petitioner establishes “sufficient
`grounds” with requisite specificity, as the discussion below shows.
`B. Anticipation — Provino
`Petitioner asserts that Provino anticipates claims 1, 7, 8, 10, 12, 13,
`15, and 17 under 35 U.S.C. § 102(e). Pet. 23–44. In support of this ground
`of unpatentability, Petitioner relies on the testimony of its declarant, Dr.
`Guerin. See Ex. 1011.
`1) Provino
`Provino’s system includes a virtual private network and an external
`device that communicates therewith in a secure manner, including by
`encryption. Ex. 1003, Abstract, 5:43–52, 6:10–28.
`
`
`
`
`
`12
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`Figure 1 of Provino follows:
`
`
`
`
`
`
`
`Figure 1 above represents Provino’s system, which includes external
`devices 12(1) –12(m), Internet 14, and VPN 15.
`
`Provino explains that to locate devices on a network, users typically
`prefer human-readable domain names, or secondary addresses, instead of
`integer-based addresses, all of which the Internet provides. These human-
`readable names (secondary addresses) must be translated, by a nameserver,
`into a digital integer or network address carried by a packet to indicate the
`destination address. Public nameservers do not have the network address for
`devices behind the firewall of a private network, such as VPN 15. Ex. 1003,
`10:45–55. Nameserver 32, behind firewall 30, in VPN 15, stores the
`associated network address and secondary address (name) of devices in the
`VPN (behind the firewall). Provino’s system provides a mechanism for
`
`13
`
`
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`device 12(m) outside the firewall to use the human-readable secondary
`address, and obtain the integer-based network address from VPN
`nameserver 32, to allow external devices 12(m) to communicate easily with
`devices behind the firewall via a secure tunnel. Ex. 1003, 1:36–65; 3:66–
`4:22; 9:32–38; 10:45–67.
`
`Provino’s device 12(m) includes secure message packet processor 26
`to facilitate a “secure tunnel . . . in secret by, for example, encrypting the
`data portion.” See Ex. 1003, 5:44–52. VPN 15 has similar devices 12(m’),
`including workstations, personal computers, etc. Id. at 6:10–28. Devices
`12(m) communicate with VPN 15 and devices 13 in VPN 15. Id. at 5:66–
`6:15. During the process of obtaining the internet addresses for the human-
`readable addresses, firewall 30 and device 12(m) cooperate “to establish a
`secure tunnel therebetween, in addition to possibly providing the device
`12(m) with . . . encryption and decryption algorithms and keys which are to
`be used in connection with the message packets transferred over the secure
`tunnel.” Id. at 10:56–67.
`
`In summary, Provino provides a secure tunnel through Internet 14 in a
`first phase to firewall 30, and in a second phase, provides the resolution
`between the human-readable names and encrypted Internet addresses for
`devices behind firewall 30 of VPN 15. Id. at 12:13–45. “Thereafter, . . .
`device 12(m) can use the integer Internet address to generate message
`packets for transfer over the Internet . . . .” Id. at 13:51–53; accord id. at
`15:27–30.
`
`Ultimately, the system provides for “easing communications . . . over
`a secure tunnel” between public devices on Internet 14 and private devices
`in VPN 15. Id. at 15:59–65. More specifically, in terms of Figure 1,
`
`14
`
`
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`Provino describes a system that facilitates encrypted communications
`between client device 12(m) connected to ISP 11 and server 31(s) located
`within VPN 15. See id. at 10:13–44; Ex. 1011 ¶¶ 28–31.
`2). Claims 1, 7, 8, 10, 12, 13, 15, and 17
`Arguing that Provino anticipates claims 1, 7, 8, 10, 12, 13, 15, and 17,
`Petitioner generally relies on Provino’s method in which client 12(m), which
`must be authorized by firewall 30, queries secure nameserver 32 through
`firewall 30 to request a secure network address for second network device
`31(s) behind firewall 30. Pet. 27–29; Ex. 1003, 9:6–31. In response to a
`human-readable Internet address sent as part of a query message, Provino’s
`system sends an encrypted Internet address for second network device 31 to
`querying client 12(m). In other words, client 12(m) obtains the response in
`part by querying secure domain nameserver 32, which is behind firewall 30.
`Firewall 30 encrypts the integer Internet address before sending it to client
`12(m). Ex. 1003, 14:39–15:30.
`On this record, according to the foregoing discussion, Petitioner has
`made a sufficient showing that Provino discloses the first listed step of claim
`1, “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.” Also, on this record,
`Petitioner has made a sufficient showing that Provino discloses the second
`listed step of claim 1, “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.” As indicated above, in
`response to the query from first network device 12(m), Provino’s secure
`nameserver 32 sends a secure network integer Internet address for second
`
`15
`
`
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`network (server) device 31 through VPN 15 firewall 30 to client 12(m). See
`Pet. 30.
`The final listed step of claim 1 recites “sending an access request
`message from the first network device to the secure network address using a
`virtual private network communication link.” After obtaining the secure
`network address and decrypting it, Provino’s network device 12(m) uses it to
`communicate with server 31(s) by sending message packets thereto. See Pet.
`32 (citing Ex. 1003, 15:27–30); Pet. 38. As Petitioner persuasively explains,
`Provino describes one embodiment of server 31(s) as a storage server, which
`provides information requested by first network device 12(m). See Pet. 33
`(citing Ex. 1003, 6:19–50; Ex. 1011 ¶¶ 39–40).
`Patent Owner contends generally that the Petition fails to explain how
`sending message packets corresponds to an “access request message” in this
`final-listed step. Prelim. Resp. 3–5. Petitioner relies on the explanation and
`disclosure noted above. Generally, as discussed above, Provino’s ultimate
`goal is to “provide[] a system for easing communications” between devices
`in a secure tunnel through a firewall that defines or corresponds to a VPN.
`Ex. 1003, 15:59–60. The communicating devices include servers, personal
`computers, workstations, and other similar devices that operate in a client-
`server relationship, where requesting client device 12(m), for example, can
`“initiate service,” and server 31(s), or a similar device, can “perform
`processing operations at the request of the client.” Id. at 6:31–46. Provino
`also explains that device 12(m) provides “one or more request message
`packets requesting the required service.” Id. at 6:52–53. Device 12(m) also
`must have “the required permissions to request [services from or access to] .
`. . device 13,” id. at 6:67–7:2, which Provino explains either is a VPN or is a
`
`16
`
`
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`computer device similar to device 12(m) or 12(m’) within a VPN. Id. at
`5:47–6:63, 8:58–62.
`Stated differently, two devices, device 12(m) and either device 13,
`12(‘m), or 31(s), ultimately participate in a secure dialog, which includes
`encryption and authentication in a secure tunnel to a VPN. See id. at 9:56–
`65; Fig. 1. Prior to encryption, device 12(m) must be authenticated during
`an initial query to create a secure encrypted dialogue with server 31(s). Id.
`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 server/computer 31(s), or thereafter, request
`encrypted information or processes from server/computer 31(s) (or other
`similar devices 12(m’) or 13). Accordingly, Petitioner sufficiently
`establishes that claim 1 reads on Provino’s system.
`Claim 7 requires the secure network address to be encrypted. Claim 8
`requires it to be decrypted. Provino’s firewall 30 encrypts the secure
`network address from nameserver 32 in a message packet. Thereafter,
`device 12(m) uses secure packet processor 36 to “decrypt the encrypted
`portion of the message packet to obtain the integer Internet address.” Ex.
`1003, 14:57–63, 15:23–27. On this record, Petitioner sufficiently establishes
`that Provino’s system encrypts and decrypts the address as claims 7 and 8
`require. See Pet. 39–40 (citing Ex. 1003, 14:57–63, 15:21–31).
`Claim 10 requires the secure network address to be “an IP address
`belonging to the second network device.” Petitioner relies on Provino’s
`disclosure of providing “an integer Internet address,” which is generally
`discussed above. See Pet. 40-41 (citing Ex. 1011). Dr. Guerin explains that
`
`17
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`
`such an Internet address is an “IP address,” or Internet Protocol address. Ex.
`1011 ¶ 34 (discussing Ex. 1003, 1:45–47). On this record, Petitioner
`sufficiently establishes that claim 10 reads on Provino’s IP system.
`Claim 12 requires “using tunneling” over the VPN. Claim 13 requires
`using “tunnel packeting” over the VPN. Provino provides a “secure tunnel,”
`as noted above, comprising connections 40, 42, and 44, between external
`device 12(m) and the VPN. See Ex. 1003, 9:32–45; Fig. 1. Provino’s
`system also encrypts portions of the Internet address and puts that in a data
`portion of a message packet. Id. at 11:25–29. The destination address of
`device 12(m) does not appear to be encrypted. Id. at 14:61–15:31.
`In support of its argument that Provino anticipates claim 12, Petitioner
`generally relies on similar showings to those discussed above and describes
`encrypting the Internet address portion as encapsulating. See Pet. 41–42.
`Based on the claim construction discussion of “tunnel packeting,” Provino’s
`placement of a device Internet address inside the data or other portion of a
`packet that is not the normal address portion (e.g. header) for that packet,
`reasonably constitutes tunnel packeting. On this record, Petitioner
`sufficiently establishes that Provino’s system reads on claims 12 and 13. See
`Pet. 41–42 (citations omitted).
`Claim 15 recites “performing the method of claim 1 with a client
`computer connected to a communication network.” Claim 15 does not
`specify how the client computer impacts the method. As noted above,
`Provino’s system employs computers in a client-server relationship.
`Petitioner generally relies on computer 12(m) as disclosing this limitation of
`claim 15. See Pet. 42–43; Ex. 1003, Fig. 1. On this record, Petitioner
`
`18
`
`
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`adequately establishes that claim 15 reads on Provino’s system, which
`includes client computer 12(m).
`Claim 17 requires the secure network address of claim 1 to be
`registered with “the secure domain service prior to the step of sending a
`query message to a secure domain service.” Petitioner explains that
`nameserver 32 in Provino provides the integer Internet address by
`associating it with a human-readable Internet address. See Pet. 43–44.
`Provino’s query message for secure information or services, as discussed
`above in connection with claim 1, occurs after the implied association was
`created in the nameserver. On this record, Petitioner sufficiently establishes
`that claim 17 reads on Provino’s system.
`Based on the foregoing discussion, Petitioner has demonstrated a
`reasonable likelihood of prevailing with respect to the anticipation of claims
`1, 7, 8, 10, 12, 13, 15, and 17 by Provino. Patent Owner generally does not
`dispute substantively Petitioner’s contentions.
`C. Obviousness — Provino and Kosiur
`Claims 2–5 depend from claim 1. Claim 2 recites “supporting a
`plurality of services over the virtual private network communication link.”
`Claim 3 depends from claim 2 and recites that “the plurality of services
`comprises a plurality of communication protocols, a plurality of application
`programs, multiple sessions, or any combination thereof.” Claim 4 depends
`from claim 3 and recites that “the plurality of application programs
`comprises video conferencing, e-mail, a word processing program,
`telephony or any combination thereof.” Claim 5 depends from claim 2 and
`recites that “the plurality of services comprises audio, video, or any
`combination thereof.”
`
`19
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`
`
`
`In arguing that claims 2–5 would have been obvious, Petitioner relies
`on Kosiur’s description of a wide variety of known features for VPNs,
`including various protocols, videoconferencing, transactional traffic,
`interactive media, IP telephony, file transfers, Web browsers, multimedia,
`and e-mail. See Pet. 46–49 (citing Ex. 1006, 9, 13, 243–249, 254; Ex. 1011
`¶¶ 41–44). Petitioner explains that such services or applications would have
`been obvious in Provino’s similar system to “increase the mobility and
`productivity of the employees operating devices” in Provino. See Pet. 47
`(citing Ex. 1011 ¶ 43); Ex. 1011 ¶¶ 41–44 (discussing Provino and Kosiur
`and the combination of the similar systems).
`At this preliminary stage of the proceedings, Petitioner provides
`sufficient reasons with supporting factual underpinnings to show that the
`combination of Provino and Kosiur would have rendered obvious challenged
`claims 2–5. Therefore, Petitioner has demonstrated that there is a reasonable
`likelihood that it would prevail with respect to the obviousness of claims 2–5
`over the combination of Provino and Kosiur.
`D. Obviousness — Provino and Xu
`Claim 18 recites “performing the method of claim 1 with a mobile
`
`device connected to a communication network through a cellular network.”
`Claim 18 does not specify how the mobile device impacts the method. Xu
`discloses a cellular telephone modem for use in a wireless corporate
`backbone LAN or Internet, with remote devices including a laptop computer
`or PDA (personal data assistant) 14. Ex. 1007, 1:7–12, 3:56–59, Fig. 1,
`Abstract. Petitioner’s declarant, Dr. Guerin, explains that Xu’s “cellular
`telephone modem” describes a cellular network of one form or another. Ex.
`1011 ¶ 45. Petitioner also relies on Xu’s description of a remote wireless
`
`20
`
`
`
`
`
`
`IPR2014-00403
`Patent 7,987,274 B2
`
`
`user connecting
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
