throbber
Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper 8
`Entered: September 11, 2015
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`
`Case IPR2015-00812
`Patent 8,850,009 B2
`
`
`
`
`
`
`
`
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`BISK, Administrative Patent Judge.
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`A. Background
`
`INTRODUCTION
`
`Petitioner, Apple Inc., filed a Petition (Paper 1, “Pet.”) requesting an
`
`inter partes review of claims 1–8, 10–20, and 22–25 (the “challenged
`
`claims”) of U.S. Patent No. 8,850,009 B2 (Ex. 1003, “the ’009
`
`patent”). Patent Owner, VirnetX Inc.,1 filed a Preliminary Response. Paper
`
`6 (“Prelim. Resp.”).
`
`We have authority to determine whether to institute an inter partes
`
`review. 35 U.S.C. § 314(b); 37 C.F.R. § 42.4(a). The standard for
`
`instituting an inter partes review is set forth in 35 U.S.C. § 314(a), which
`
`provides that an inter partes review may not be instituted “unless the
`
`Director determines . . . there is a reasonable likelihood that the petitioner
`
`would prevail with respect to at least 1 of the claims challenged in the
`
`petition.”
`
`After considering the Petition and Preliminary Response, we
`
`determine that Petitioner has established a reasonable likelihood of
`
`prevailing in showing the unpatentability of at least one of the challenged
`
`claims. Accordingly, we institute inter partes review.
`
`B. Related Matters
`
`The parties indicate that the ’009 patent “and/or” related patents are
`
`involved in several proceedings in the United States District Court for the
`
`
`1 The Petition also names Science Application International Corporation as
`Patent Owner. However, the Patent Owner Preliminary Response names
`only VirnetX.
`
`2
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`Eastern District of Texas.2 Pet. 6–7; Paper 5, 12–13. Petitioner also filed
`
`another petition seeking inter partes review of the ’009 patent—IPR2015-
`
`00813. Pet. 2. In addition, many other inter partes review and inter partes
`
`reexamination proceedings challenging related patents are currently, or have
`
`been recently, before the Office.3
`
`C. The Asserted Grounds of Unpatentability
`
`Petitioner contends that claims 1–8, 10–20, and 22–25 of the ’009
`
`patent are unpatentable under 35 U.S.C. § 103 based on the combination of
`
`Beser4 and RFC 2401.5 Petitioner also provides testimony from Dr. Roberto
`
`Tamassia. Ex. 1005.
`
`D. The ’009 Patent
`
`The ’009 patent describes secure methods for communicating over the
`
`Internet. Ex. 1003, 10:16–17. Specifically, the ’009 patent describes “the
`
`automatic creation of a virtual private network (VPN) in response to a
`
`
`2 In the future, Petitioner is advised that referring to “numerous lawsuits,”
`without specifically identifying the court in which the lawsuit is taking place
`and other information necessary to identify the proceeding may be
`considered a violation of 37 C.F.R. § 42.8. See Pet. 6–7. Similarly, Patent
`Owner is advised to be specific in addressing whether the challenged patent
`is actually the subject of the enumerated related litigation. See Paper 5, 12–
`13.
`3 In this section, the Petition did not identify specifically any other
`proceeding before the Office other than IPR2015-00813. Pet. 2. In the
`future, such omission may be construed as a violation of 37 C.F.R. § 42.8.
`4 U.S. Patent No. 6,496,867 B1 (Ex. 1007) (“Beser”).
`5 S. Kent and R. Atkinson, Security Architecture for the Internet Protocol,
`Request for Comments: 2401, BBN Corp., November 1998 (Ex. 1008)
`(“RFC 2401”).
`
`3
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`domain-name server look-up function.” Id. at 39:36–38. This automatic
`
`creation makes use of a modified Domain Name Server as opposed to a
`
`conventional Domain Name Server (DNS), which is described as follows:
`
`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.
`
`Id. at 39:39–45.
`
`The modified DNS server may include both a conventional
`
`DNS and a DNS proxy. Id. at 40:33–35. The DNS proxy of the
`
`modified DNS server intercepts all DNS lookup requests, determines
`
`whether the user has requested access to a secure site (using for
`
`example, a domain name extension or an internal table of secure sites)
`
`and if so, whether the user has sufficient security privileges to access
`
`the requested site. Id. at 40:39–45. If the user has requested access to
`
`a secure site to which it has insufficient security privileges, the DNS
`
`proxy returns a “‘host unknown’” error to the user. Id. at 40:62–65.
`
`If the user has requested access to a secure site to which it has
`
`sufficient security privileges, the DNS proxy requests a gatekeeper to
`
`create a VPN between the user’s computer and the secure target site.
`
`Id. at 40:45–51. The DNS proxy then returns to the user the resolved
`
`address passed to it by the gatekeeper, which need not be the actual
`
`address of the destination computer. Id. at 40:51–57.
`
`The VPN is “preferably implemented using the IP address
`
`‘hopping’ features,” (changing IP addresses based upon an agreed
`
`4
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`upon algorithm) described elsewhere in the ’009 patent, “such that the
`
`true identity of the two nodes cannot be determined even if packets
`
`during the communication are intercepted.” Id. at 40:18–22.
`
`E. Illustrative Claim
`
`Claims 1 and 14 of the ’009 patent are independent. Claim 1 is
`
`illustrative of the claimed subject matter and recites:
`
`1. A network device, comprising:
`
`a storage device storing an application program for a secure
`communications service; and
`
`at least one processor configured to execute the application
`program for the secure communications service so as to
`enable the network device to:
`
`send a domain name service (DNS) request to look up a
`network address of a second network device based on an
`identifier associated with the second network device;
`
`receive, following interception of the DNS request and a
`determination that the second network device is available for
`the secure communications service: (1) an indication that the
`second network device
`is available
`for
`the secure
`communications service, (2) the requested network address
`of
`the second network device, and (3) provisioning
`information for an encrypted communication link;
`
`connect to the second network device over the encrypted
`communication link, using the received network address of
`the second network device and the provisioning information
`for the encrypted communication link; and
`
`communicate data with the second network device using the
`secure
`communications
`service via
`the
`encrypted
`communication link,
`
`the network device being a device at which a user uses the
`secure communications service to access the encrypted
`communication link.
`
`5
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`Ex. 1003, 56:22–48.
`
`A. Claim Construction
`
`ANALYSIS
`
`We interpret claims of an unexpired patent using the broadest
`
`reasonable construction in light of the specification of the patent in which
`
`they appear. 37 C.F.R. § 42.100(b); see In re Cuozzo Speed Techs., LLC.,
`
`No. 2014-1301, 2015 WL 4097949, at *5–*8 (Fed. Cir. July 8, 2015), reh’g
`
`en banc denied, 2015 WL 4100060 (Fed. Cir. July 8, 2015). We presume a
`
`claim term carries its “ordinary and customary meaning,” which is “the
`
`meaning that the term would have to a person of ordinary skill in the art in
`
`question” at the time of the invention. In re Translogic Tech., Inc., 504 F.3d
`
`1249, 1257 (Fed. Cir. 2007) (citation and quotations omitted).
`
`Petitioner and Patent Owner each proffer proposed constructions of
`
`several claim terms. At this stage of the proceeding, neither party has
`
`identified a term for construction that is dispositive on any of the challenges.
`
`For the purposes of this Decision, and on this record, we determine that no
`
`claim term needs express interpretation. See Vivid Techs., Inc. v. Am. Sci. &
`
`Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999) (only those terms which are
`
`in controversy need to be construed, and only to the extent necessary to
`
`resolve the controversy).
`
`B. Prior Art Printed Publication Status of RFC 2401
`
`Patent Owner asserts that Petitioner “does not provide evidence to
`
`establish that RFC 2401 would have been sufficiently accessible to the
`
`public interested in the art” on November 1998, the date recited on each of
`
`its pages. Prelim. Resp. 3. According to Patent Owner, Petitioner fails to
`
`show that RFC 2401 constitutes a prior art printed publication and is
`
`6
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`therefore not properly relied upon for purposes of showing obviousness. Id.
`
`at 3–6. On this basis, Patent Owner argues that Petitioner has not satisfied
`
`its burden of showing a reasonable likelihood of prevailing with respect to
`
`any challenged claim of the ’009 patent.
`
`The determination of whether a given reference qualifies as a prior art
`
`“printed publication” involves a case-by-case inquiry into the facts and
`
`circumstances surrounding the reference’s disclosure to members of the
`
`public. In re Klopfenstein, 380 F.3d 1345, 1350 (Fed. Cir. 2004). We
`
`acknowledge Patent Owner’s argument regarding RFC 2401. On its face,
`
`however, RFC 2401 is a dated “Request for Comments” from the “Network
`
`Working Group,” discussing a particular standardized security protocol for
`
`the Internet. Ex. 1008. Moreover, RFC 2401 describes itself as a
`
`“document [that] specifies an Internet standards track protocol for the
`
`Internet community, and requests discussion and suggestions for
`
`improvements. . . . Distribution of this memo is unlimited.” Id. at 1; see also
`
`Ex. 1005 ¶¶ 148–155 (discussing Request for Comment (“RFC”)
`
`publications). These indicia suggest that there is a reasonable likelihood the
`
`document was made available to the public (over the Internet), in order to
`
`obtain feedback prior to implementation of the standard it describes.
`
`On this record,6 we are persuaded that Petitioner has made a threshold
`
`showing that RFC 2401 constitutes a prior art printed publication.
`
`
`6 To the extent that Patent Owner objects to the admissibility of this
`evidence, it will have the opportunity, after trial is instituted, to enter any
`objections to evidence. 37 C.F.R. § 42.64(b)(1). To the extent that Patent
`Owner continues to assert that Petitioner has not met its burden of showing
`that RFC 2401 is a “printed publication,” it will have the opportunity to
`make this argument in its Patent Owner Response.
`
`7
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`Accordingly, we consider the disclosure of RFC 2401 for the purposes of
`
`this decision.
`
`C. Obviousness Over Beser and RFC 2401
`
`1. Overview of Beser
`
`Beser describes a system that establishes an IP (internet protocol)
`
`tunneling association on a public network between two end devices. See Ex.
`
`1007, Abs. Figure 1 of Beser is reproduced below.
`
`Figure 1 of Beser illustrates a network system, including public network 12,
`
`network devices 24 and 26, private network 20, trusted third-party network
`
`
`
`
`
`
`8
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`device 30, and modified routers or gateways 14 and 16. Ex. 1007, 3:60–
`
`4:19. Beser describes network devices 24 and 26 as telephony devices,
`
`multimedia devices, VoIP devices, or personal computers. Id. at 4:43–52.
`
`Beser’s system “increases the security of communication on the data
`
`network” by providing and hiding, in packets, “private addresses” for
`
`originating device 24 and terminating device 26 on the network. See id. at
`
`Abs., Fig. 1, Fig. 6. To begin a secure transaction, requesting device 24
`
`sends a request to initiate a tunneling connection to network device 14. Id.
`
`at 8:21–47. This request includes a unique identifier for the terminating end
`
`of the tunneling association—terminating device 26. Id.at 7:64–8:3. The
`
`packets used to transfer this unique identifier across the public network
`
`“may require encryption or authentication to ensure that the unique identifier
`
`cannot be read on the public network.” Id. at 11:22–25. Beser discloses, as
`
`background prior art, known forms of encryption for the information inside
`
`these packets, including IP Security (“‘IPsec’”). Id. at 1:54–56. Once
`
`network device 14 receives the request, it passes the request on to trusted-
`
`third-party network device 30. Id. at 8:3–4, 8:48–9:5.
`
`Trusted-third-party network device 30 contains a directory of users,
`
`such as a DNS, which retains a list of public IP addresses associated at least
`
`with second network device 16 and terminating devices 26. See id. at
`
`11:32–58. DNS 30 associates terminating network device 26, based on its
`
`unique identifier in the request, with a public IP address for router device 16.
`
`See id. at 11:26–36. Trusted-third-party network device 30 then assigns, by
`
`negotiation, private IP addresses to requesting network device 24 and
`
`terminating device 26. Id. at 9:29–35, 12:17–19. The negotiated private IP
`
`9
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`addresses are “isolated from a public network such as the Internet,” and “are
`
`not globally routable.” Id. at 11:62–65.
`
`2. Overview of RFC 2401
`
`RFC 2401 describes the security services offered by the IPsec
`
`protocols, including “access control, connectionless integrity, data origin
`
`authentication, [and] . . . confidentiality (encryption).” Ex. 1008, 3–4.
`
`3. Claims 1 and 14
`
`For this proceeding, Petitioner asserts that the “non-encrypted
`
`streaming audio/video example” described in Beser teaches each of the
`
`limitations of claims 1 and 14 except the required “encrypted
`
`communications link.” Pet. 28–29, 34–50. Specifically, Petitioner argues
`
`that Beser’s originating end device is equivalent to the claimed first network
`
`device and Beser’s terminating end device is equivalent to the claimed
`
`second network device. Pet. 34–35. Petitioner also argues that Beser
`
`discloses the trusted-third-party network device, intercepting a DNS request
`
`and determining that the terminating end device is available. Pet. 35–44.
`
`According to Petitioner, it would have been obvious to a person of ordinary
`
`skill in the art to provide “‘end-to-end’” encryption of the traffic being sent
`
`in Beser using the teachings of RFC 2401. Id. at 29–30.
`
`a. Rationale to Combine
`
`Petitioner argues that “a person of ordinary skill would have
`
`considered the teachings of Beser in conjunction with those in RFC 2401
`
`because Beser expressly refers to the IPsec protocol (which is defined in
`
`RFC 2401) as being the conventional way that the IP tunnels described in
`
`Beser are established. Pet. 30 (citing Ex. 1007, 1:54–56; Ex. 1005 ¶¶ 383–
`
`10
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`85, 395). Petitioner adds that Beser also indicates that “its IP tunneling
`
`schemes are compliant with standards-based processes and techniques (e.g.,
`
`IPsec), and can be implemented using pre-existing equipment and systems”
`
`and that “IP tunnels are and should ordinarily be encrypted.” Id. at 30–31
`
`(citing Ex. 1007, 1:54–56, 4:55–5:2, 11:22–25, 18:2–5; Ex. 1005 ¶¶ 282–83,
`
`185, 383–86, 389–90, 394, 398). Moreover, Petitioner adds that a person of
`
`ordinary skill would have recognized that IPsec readily could be integrated
`
`into Beser’s systems. Id. at 31–32 (citing Ex. 1005 ¶¶ 391, 392, 398–400).
`
`Patent Owner argues that Beser and RFC 2401 would not have been
`
`combined as asserted by Petitioner. Prelim. Resp. 12–17. According to
`
`Patent Owner, Beser teaches away from using the IPsec protocol of RFC
`
`2401 for audio or data by explaining that streaming data flows, such as
`
`multimedia, require a great deal of computing power to encrypt or decrypt
`
`and the “strain of such computations ‘may result in jitter, delay, or the loss
`
`of some packets.’” Id. at 13 (quoting Ex. 1007, 1:64–65). Thus, Patent
`
`Owner concludes that “one of ordinary skill in the art would understand that
`
`Beser is directed to providing a method for securing communications other
`
`than encryption.” Id. at 14 (citing Ex. 2009 ¶ 56). Patent Owner adds that
`
`Beser “also teaches that encryption does not deter a determined hacker from
`
`deducing source and identity information, and so, once the tunnel is
`
`established, Beser eschews encryption in favor of hiding the identities within
`
`the tunnel” and, thus, adding encryption would “contravene Beser’s express
`
`objective of increasing security without increasing computational burden.”
`
`Id. at 15.
`
`We are not persuaded, at this point in the proceeding, that Beser
`
`teaches away from adding encryption to its system. Although Beser
`
`11
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`recognizes that the use of encryption may cause challenges, it also suggests
`
`that such problems may be overcome by providing more computer power.
`
`Ex. 1007, 1:60–63. In addition, Beser characterizes some prior art systems
`
`as creating “security problems by preventing certain types of encryption
`
`from being used.” Ex. 1007, 2:23–24. We are, therefore, persuaded that
`
`Petitioner’s rationale that a person of ordinary skill would have found it
`
`obvious to combine the teachings of RFC 2401 with Beser is reasonable.
`
`b. The Receiving Limitation
`
`Patent Owner also argues that Petitioner improperly relies on two
`
`elements in Beser for three separate claimed features. Prelim. Resp. 17–20.
`
`Specifically, claims 1 and 14 recite a first network device
`
`receiv[e/ing], following interception of the DNS request and a
`determination that the second network device is available for a
`secure communications service: (1) an indication that the
`second network device is available for the secure
`communications service, (2) the requested network address of
`the second network device, and (3) provisioning information for
`an encrypted communication link.
`
`(“the receiving limitation”). According to Patent Owner, Petitioner
`
`improperly contends that the three enumerated features of the receiving
`
`limitation are satisfied by Beser’s receipt, at the originating end device, of its
`
`own private IP address and the private IP address of the terminating end
`
`device. Id. at 18. Patent Owner appears to base this argument on some
`
`language in the Petition stating that the originating end device’s private IP
`
`address could be used to satisfy both the “‘indication’” feature and the
`
`“provisioning information” feature of the receiving limitation. Id. (quoting
`
`Pet. 46 (discussing not the receiving limitation, but the “connecting”
`
`limitation). Patent Owner adds that “Petitioner has not argued that one of
`
`12
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`skill would have found it obvious to either replace the three separate claim
`
`features with two features that perform multiple functions or add an
`
`additional element to Beser to be received by the originating device.” Id. at
`
`19.
`
`We do not agree with Patent Owner that Petitioner’s arguments are so
`
`limited. In fact, Petitioner argues that, with respect to provisioning
`
`information, in the example being asserted, “Beser would not provide
`
`provisioning information for an encrypted communication link,” but that
`
`providing such information “would have been an obvious variation of Beser
`
`in view of RFC 2401.” Pet. 42–43. Moreover, Petitioner argues that “RFC
`
`2401 also describes providing ‘provisioning information’” in the form of key
`
`distribution and states that “[i]t would have been obvious to configure the
`
`trusted-third-party network device to play this role” and “provide an
`
`encryption key to be used to encrypt the communications between the end
`
`devices according to IPsec.” Id. at 44. Patent Owner does not address these
`
`arguments in its Preliminary Response.
`
`c. Conclusion
`
`On this record, in view of Petitioner’s reliance on the testimony of Dr.
`
`Tamassia, which we credit, we are persuaded Petitioner has established a
`
`reasonable likelihood of prevailing in its challenge that claims 1 and 14
`
`would have been obvious over Beser combined with RFC 2401.
`
`4. Claims 2–8, 10–13, 15–20, and 22–25
`
`Petitioner asserts that the combination of Beser and RFC 2401 teaches
`
`each of the limitations of claims 2–8, 10–13, and 22–25. Pet. 50–59 (citing
`
`Ex. 1005). In its Preliminary Response, Patent Owner does not make
`
`specific arguments directed to these claims. On this record, we are
`
`13
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`persuaded Petitioner has established a reasonable likelihood of prevailing in
`
`its challenge that claims 2–8, 10–13, and 22–25 would have been obvious
`
`over Beser combined with RFC 2401.
`
`CONCLUSION
`
`For the foregoing reasons, we determine that the information
`
`presented in the Petition establishes that there is a reasonable likelihood that
`
`Petitioner would prevail with respect to the challenged claims of the ’009
`
`patent.
`
`Any discussion of facts in this decision are made only for the purposes
`
`of institution and are not dispositive of any issue related to any ground on
`
`which we institute review. The Board has not made a final determination on
`
`the patentability of any challenged claims. The Board’s final determination
`
`will be based on the record as fully developed during trial.
`
`Accordingly, it is
`
`ORDER
`
`ORDERED that pursuant to 35 U.S.C. § 314, we institute an inter
`
`partes review of claims 1–8, 10–20, and 22–25 of the ’009 patent as obvious
`
`over Beser and RFC 2401.
`
`FURTHER ORDERED that pursuant to 35 U.S.C. § 314(c) and
`
`37 C.F.R. § 42.4, notice is hereby given of the institution of a trial;
`
`FURTHER ORDERED that the trial is limited to the grounds
`
`14
`
`identified above.
`
`
`
`

`
`IPR2015-00812
`Patent 8,850,009 B2
`
`PETITIONER:
`Jeffrey P. Kushan
`Scott Border
`Thomas A. Broughan, III
`SIDLEY AUSTIN LLP
`jkushan@sidley.com
`sborder@sidley.com
`tbroughan@sidley.com
`iprnotices@sidley.com
`
`
`
`PATENT OWNER:
`Joseph E. Palys
`Naveen Modi
`PAUL HASTINGS LLP
`josephpalys@paulhastings.com
`naveenmodi@paulhastings.com
`
`Jason Stach
`FINNEGAN, HENDERSON, FARABOW,
`GARRETT & DUNNER, L.L.P.
`jason.stach@finnegan.com
`
`
`
`
`
`
`
`
`
`15

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket