- Apple Inc. v. Virnetx Inc.Some claims unpatentablePTAB · Aug 24, 2015 · IPR2014-00482 · APJ Stephen C Siu · IPR · Final written decision
Claims 1, 4, 6, 10, 13–15, 17, 20, 22, 26, 29–31, 33, 35, and 37 are unpatentable; claims 12 and 28 were not shown unpatentable.
RulingsFinal written decision- Claim Construction › Threshold & procedure › Whether a term needs construction (O2 Micro)Term construed board ownDecided for patent owner
“We previously determined that, under a broad but reasonable construction, one of skill in the art would have understood the term “virtual private network communication link,” in light of the Specification, to include “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.” Dec. on Inst. 6–7. 1 Patent Owner disputes this interpretation and argues that the term “virtual private network communication link” must be “a communication path between computers in a virtual private network” (PO Resp. 8), “requir[es] computers within a VPN to communicate directly” (PO Resp. 10), and requires a “network of computers,” which, according to Patent Owner must be “more than a ‘path between two devices.’” PO Resp. 14. We decline to modify our previous construction of this term in the manner suggested by Patent Owner because such a modification is immaterial in this proceeding for reasons set forth below. See Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999) (claim terms need only be construed to the extent necessary to resolve the case).” slip op. at 3
- Claim Construction › Intrinsic evidence (Phillips canons) › Plain and ordinary meaning to a POSITATerm construed board ownDecided for patent owner
“understood that a “secure computer network address” must be “associated with a computer capable of virtual private network communications” because a claim recites “sending an access request message to the secure computer network address using a virtual private network communication link.” PO Resp. 16. We agree with Patent Owner that claim 1, for example, recites “sending an access request message to the secure computer network address using a virtual private network communication link.” However, Patent Owner does not explain sufficiently why an explicitly recited claim limitation must be incorporated into the construction of an associated claim term. Indeed, if one of ordinary skill in the art would have understood that all secure computer network addresses must be associated with a computer capable of VPN communications and that any computer network address that is associated with computers that are incapable of VPN communications would be understood by one of ordinary skill in the art not to be a “secure computer network address” (even if authorization for access is required), then any such recited claim limitation would be superfluous. Patent Owner also argues that “VirnetX’s proposed construction has been agreed to by its litigation adversaries and has been adopted by a district court.” PO Resp. 17. Even if Patent Owner’s proposed construction “has been agreed to by” parties in litigation and the district court, Patent Owner does not assert or demonstrate persuasively that one of ordinary skill in the art would have broadly but reasonably construed the term “secure computer network address” in light of the Specification to require association with a computer capable of virtual private network communications. In any event, Patent Owner does not appear to contend that the cited references fail to disclose a secure computer network address that is associated with a computer capable of VPN communications and, therefore, does not demonstrate sufficiently that the construction of “secure computer network address” will bear on the outcome of the issues in this inter partes review. We decline to modify our construction of this term.” slip op. at 5
- Novelty / Anticipation (§102) › Anticipation standard (single reference, every element)UnpatentableNot shown unpatentableMixed
“computer network address” of “the server-side proxy” (and not the “host”). PO Resp. 32 (emphasis omitted). In other words, Patent Owner argues that, in contrast to claim 1, which requires sending a query message requesting an address and receiving a response message containing the address requested in the query message, Kiuchi discloses sending a query message requesting an address of “the host” but receiving a response message containing an address of “the server-side proxy,” rather than “the host.” Based on this presumption that “the host” of Kiuchi differs from the “server-side proxy” of Kiuchi, Patent Owner argues that Kiuchi fails to disclose the claimed invention and also that “the Board has exceeded its statutory authority by instituting in part on rationales that were not before it.” PO Resp. 30. However, Patent Owner does not explain sufficiently a difference between “the host” and the “server-side proxy” of Kiuchi. Kiuchi discloses that a client-side proxy “asks the C-HTTP name server whether it can communicate with the host” and that, in response, the C-HTTP name server examines “the requested server-side proxy” and responds by sending the IP address of the server-side proxy. Ex. 1004, 65 (emphasis added). In other words, Kiuchi discloses that “the host” that is requested is the requested “server-side proxy.”” slip op. at 13
- Obviousness (§103) › Motivation to combine / reasonable expectation of successMotivation foundUnpatentableMixed
“of ordinary skill in the art would have combined Kiuchi with the other references.” PO Resp. 3. Petitioner provides reasons with supporting factual underpinnings to support the conclusion that the combination of Kiuchi and Bhatti (and/or Tavs) would have been obvious to one of ordinary skill in the art. Pet. 34–35, 38–39. For example, Petitioner states that one of ordinary skill in the art would implement Kiuchi’s user agent such that the user agent sends an access request for content stored on the origin server, in the same manner that Bhatti describes sending an access request from a user terminal for content stored [on] a content server. Pet. 38. Petitioner also states that “[i]t would have been obvious to one of ordinary skill at the time of the ’180 patent to modify the client-side proxy and server-side proxy described by Kiuchi to support the service-level categorization and differentiation described by Tavs in order to give priority to business-relevant traffic during peak network congestion.” Pet. 34. Patent Owner does not dispute the reasons provided by Petitioner as to why it would have been obvious to one of ordinary skill in the art to have combined teachings of Kiuchi and Bhatti (and/or Tavs) but argues that this obviousness ground “is critically flawed because the Petition relies solely on missing expert testimony for its rationale for combining” the references. PO Resp. 54, 56. However, Patent Owner does not explain why Petitioner is required to provide expert testimony in support of a proposed ground of unpatentability. Nor does Patent Owner explain the supposed flaws in the rationale provided by Petitioner.” slip op. at 21
Patent outcomesUS 7,188,180 mixedClaim construction§ 102 anticipation§ 103 obviousnesscites Phillips · KSRPatents in suitUS 7,188,180 - Apple Inc. v. Virnetx Inc.All claims unpatentablePTAB · Aug 24, 2015 · IPR2014-00481 · APJ Karl D Easthom · IPR · Final written decision
Claims 1, 10, 12–15, 17, 26, 28–31, and 33 are unpatentable as anticipated by Provino; claims 4, 6, 20, 22, 35, and 37 are unpatentable as obvious over Provino and Guillen.
RulingsFinal written decision- Claim Construction › Intrinsic evidence (Phillips canons) › Plain and ordinary meaning to a POSITATerm construed petitioner constructionDecided for petitioner
“It does not recite “recogniz[ing] that the query message is requesting a secure computer address.” “[T]he claims themselves provide substantial guidance as to the meaning of particular claim terms” and “the context in which a term is used in the asserted claim can be highly instructive.” Phillips, 415 F.3d at 1314. “The construction that stays true to the claim language and most naturally aligns with the patent’s description of the invention will be, in the end, the correct construction.” Phillips, 415 F.3d at 1316 (citations omitted). Based on the context of the claim, the Specification, and the prosecution history, claim 1 does not require “recogniz[ing]” as argued by Patent Owner. As explained in the Background section supra, the Specification describes an “SDNS 3313” that “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.” Ex. 1001, 52:4–8. This disclosure comes closest to aligning with the claim term by explaining how a “secure domain name service” (i.e., an SDNS as set forth in the disclosure) operates. Patent Owner does not point the panel to a disclosure in the Specification that clearly supports the requirement of an SDNS to “recognize that the query message is requesting a secure computer address.”” slip op. at 15
- Claim Construction › Threshold & procedure › Whether a term needs construction (O2 Micro)No construction neededDecided for petitioner
“6. Access Request Message As Patent Owner explains, the construction of this term “do[es] not appear to be relevant to the parties’ disputes.” PO Resp. 23.” slip op. at 27
- Novelty / Anticipation (§102) › Anticipation standard (single reference, every element)UnpatentableUnpatentable
“that under the claim construction of a “secure domain name” as “a name that corresponds to a secure computer network address,” “Patent Owner . . . concedes Provino discloses this limitation.” Pet. Reply 6–7 (citing Ex. 1003, 13:31–40, 10:45–67; Resp. 26; Ex. 2024 ¶ 28; Ex. 1011 ¶¶ 29–33; Inst. Dec. 8). Petitioner’s argument and showing is persuasive. The claim element does not require any verification that the name is secure.7 Patent Owner also argues that Provino does not teach “receiving a secure domain name” because Provino uses “standard” domain names. PO Resp. 29. Patent Owner points to its Specification that allegedly discusses “an exemplary ‘standard’ domain name ending in ‘.com’ and an exemplary ‘non-standard’ domain name ending in ‘scom.’” PO Resp. 28 (citing Ex. 1001, 51:16–17; Ex. 2024 ¶ 31). These exemplary embodiments do not alter the broadest reasonable claim construction of a “secure domain name.” See supra Section I.E.3., I.E.4. (Claim Construction). As also noted above (id.), Patent Owner made the opposite argument to a district court, and argued that a “non-standard” distinction “is not supported by the specification or the prosecution history.” Ex. 1018, 18.” slip op. at 28
- Obviousness (§103) › Motivation to combine / reasonable expectation of successMotivation foundUnpatentable
“Petitioner responds to Patent Owner’s argument as follows: [I]n Provino, before this path between device 12(M) and server 31(s) can exist, nameserver 32 must provide server 31(s)’s secure address. . . . If, in the same response message, a modified nameserver 32 provides QoS parameters, that would necessarily be before the relevant path is established, contrary to Patent Owner’s assertions. Pet. Reply 14 (citing Ex. 1003, 10:56–11:45; Ex. 1011 ¶ 39; Ex. 1089, 58:17–59:16; Ex. 2019, 51:21–55:6). Similarly, according to the Petition, “a person of ordinary skill in the art would have modified the VPN name server 32 of Provino to store, in part, topology dependent QoS parameters, as described by Guillen,” and “[s]uch a modified VPN name server 32 would . . . respond to requests by device 12(m) to resolve the human-readable network addresses of servers 31(S) with both the integer Internet address of the servers 31(S) and the QoS parameters for the servers 31(S).” Pet. 38 (citing Ex. 1011 ¶ 43, Ex. 1005, 82, § 2.3). Petitioner adds that “one of skill would combine Guillen and Provino based on the parallel uses of DNS servers.” Pet. Reply 14 (quoting Ex. 1011 ¶ 42). At the cited paragraph, Dr. Guerin reasons that “Provino relies upon DNS servers to perform address resolution in the context of VPNs in the same manner as Guillen describes their use in the context of ATM communications.” Ex. 1011 ¶ 42 (citing Ex. 1003, 10:45–67). Dr. Guerin also relies on Guillen’s disclosure of using DNS directory servers for address resolution and storing values of QoS parameters to suggest providing indications of feasible QoS levels during address resolution. Ex. 1011 ¶ 41 (citing Ex. 1005, 82, § 2.3). Dr. Guerin also cites Guillen as teaching that QoS parameters relate to guarantees such as bandwidth, and other service requirements, required for multimedia applications, so that “the multimedia application can properly function.” Id. ¶ 40 (citing Ex. 1005, Abstract, 80–82, §§ 2.1, 2.3, 2.4). As outlined above, the parties agree that if the modification would have been obvious, it would apply during address resolution to set up Provino’s tunnel. The parties do not disagree materially, if at all, about what Guillen teaches. On balance, Guillen supports Petitioner’s rationale. See Ex. 1005, 80–82. However, according to Patent Owner, the proposed modification of Provino’s’ nameserver could not work, because “by the time Provino’s device 12(m) accesses nameserver 32, device 12(m) and firewall 30 have already cooperated to establish the tunnel.” PO Resp. 50. Patent Owner’s argument about “access[]” confounds the claim terms” slip op. at 43
Patent outcomesUS 7,188,180 unpatentableClaim construction§ 102 anticipation§ 103 obviousnesscites Phillips · KSRPatents in suitUS 7,188,180 - Apple Inc. v. Virnetx Inc.All claims unpatentablePTAB · Jul 29, 2015 · IPR2014-00403 · APJ Karl D Easthom · IPR · Final written decision
The Board held claims 1–5, 7, 8, 10, 12, 13, 15, 17, and 18 unpatentable: Provino anticipated claims 1, 7, 8, 10, 12, 13, 15, and 17; combinations with Kosiur and Xu rendered claims 2–5 …
RulingsFinal written decision- Claim Construction › Intrinsic evidence (Phillips canons) › Prosecution history disclaimer / disavowalTerm construed petitioner constructionDecided for petitioner
“proceeding somehow limits the claims here that Patent Owner otherwise could have moved to amend under a broadest reasonable construction, Patent Owner’s arguments were not “unambiguous,” and do not “call for the application of prosecution history disclaimer.” See PO Resp. 17–18. There was no “express disclaimer,” Bigio, 381 F.3d at 1325, or “unambiguous disavowal[],” Grober, 686 F.3d at 1341.” slip op. at 11
- Claim Construction › Threshold & procedure › Whether a term needs construction (O2 Micro)No construction neededDecided for petitioner
“5. Access Request Message As Patent Owner explains, the construction of this term “do[es] not appear to be relevant to the parties’ disputes.” PO Resp. 24. 6. Secure Network Address As Patent Owner explains, the construction of this term “do[es] not appear to be relevant to the parties’ disputes.” PO Resp. 24.” slip op. at 24
- Novelty / Anticipation (§102) › Anticipation standard (single reference, every element)UnpatentableUnpatentable
“dispute that Provino’s SDNS resolves secure domain names into secure network addresses, thereby satisfying the claim construction of a secure domain service, as discussed above and further below. See Pet. Reply 8. Further, Provino’s VPN nameserver 32 resides behind a firewall, which controls access to secure devices 31(s), indicating it is secure for that additional reason.10 Ex. 1003, Fig. 1, 9:6–17. The fact that nameservers 17 and 32 perform similar functions simply demonstrates that they are both nameservers. In addition, Provino’s SDNS 32 “is generally similar to . . . nameserver [17], except that the integer Internet address will be provided by the nameserver 32 in a message packet directed to the firewall 30, and the firewall 30 will thereafter transmit the message packet over the secure tunnel to the device 12(m).” Ex. 1003, 11:20–25. In other words, even under Patent Owner’s narrow claim construction that requires an SDNS to perform an additional function (i.e., in addition to resolving a secure domain name (see PO Resp. 16–18)), unlike conventional nameserver 17, secure nameserver 32 directs a message packet to firewall 30, and thereby performs” slip op. at 25
- Obviousness (§103) › Motivation to combine / reasonable expectation of successUnpatentableMotivation foundUnpatentable
“artisans would have recognized that Provino’s scheme could have been used to transmit videoconferencing. Pet. Reply 14–15 (citing Ex. 1011 ¶ 42; Ex. 1006, 9, 249, 254; Ex. 1003, 4:35–49, 5:28–35). For example, Petitioner points out that “[a]lthough Provino does not specifically address these [videoconferencing and other claimed applications], it does describe device 12(m) as a system unit having the requisite capabilities, including a video display ‘to display processed data,’ and explains that message packets received ‘contain information such as web pages or the like, . . . to be displayed on the device’s video display unit.’” Id. at 15 (quoting Ex. 1003, 4:35–49, 5:28–35). This record indicates that videoconferencing simply constitutes similar packet data traffic to the traffic that Provino’s system implements. Petitioner also points out that “even Patent Owner’s expert admitted that ‘[Provino is] generally saying that you can send data, and one such type of data is video;’ and could not identify any reason why sending video data on the Provino system would present insoluble problems.” Id. (citing Ex. 1090, 46:12–13, 48:2–7). Dr. Monrose’s deposition testimony supports Petitioner’s characterization of it. For example, Dr. Monrose states that “he didn’t opine on whether or not there’s anything in Provino that would explicitly not allow the sending of video data. This is not in my declaration, as far as I recall.” Ex. 1090, 48:2–7. Dr. Monrose also did not “reflect on . . . whether [data packets that represent video] will be processed differently or not, and how that could impact the operations of Provino.” See id. at 46:17–47:3 (responding to a question during cross-examination). Petitioner further points out that Kosiur provides a “‘background on VPN technologies and products,’ Ex. 1006 at 9, and explain[s] that VPNs can support ‘newer applications, such as interactive multimedia and videoconferencing,’ id. at 254, as well as ‘file transfers, Web browsing, and e-mail,’ id. at 249.” Pet. Reply 14 (quoting Ex. 1006, citing Ex. 1011 ¶ 42). The record suggests that an ordinarily skilled artisan would have recognized that Provino’s system, which sends packets of data over a VPN, including webpages for viewing on a display, could have been modified in a beneficial and predictable fashion, as Kosiur suggests, to send similar packet data to provide videoconferencing on a similar display. “[I]f a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious unless its actual application is beyond his or her skill.” KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007).” slip op. at 36
Patent outcomesUS 7,987,274 unpatentableClaim construction§ 102 anticipation§ 103 obviousnesscites Phillips · KSRPatents in suitUS 7,987,274 - Apple Inc. v. Virnetx Inc.All claims unpatentablePTAB · Jul 29, 2015 · IPR2014-00404 · APJ Stephen C Siu · IPR · Final written decision
Claims 1–5, 7, 8, 10, 12, 15, and 17 are unpatentable: claims 1–4, 7, 8, 10, 12, 15, and 17 under § 102 and § 103; claim 5 under § 103.
RulingsFinal written decision- PTAB / AIA Trials › Joinder §315(c) / SAS all-or-nothingOther
“seeking an inter partes review of claims 1–5, 7, 8, 10, 12, 13, 15, 17, and 18 of the ’274 patent pursuant to 35 U.S.C. §§ 311–319. On September 15, 2014, the Board instituted an inter partes review of claims 1–5, 7, 8, 10, 12, 15, and 17 (IPR2014-00484) and joined IPR2014-00484 with IPR2014- 00404 pursuant to 35 U.S.C. § 315(c) (IPR2014-00484, Paper 11 – Dec. on Inst.). On April 16, 2015, the present proceeding was terminated with respect to Microsoft Corporation only. Paper 38.” slip op. at 2
- Claim Construction › Intrinsic evidence (Phillips canons) › Plain and ordinary meaning to a POSITATerm construed petitioner constructionDecided for petitioner
“domain service” requesting a secure network address and receiving “a response message from the secure domain name service containing the secure network address.” Claim 1 does not recite “recogniz[ing] that the query message is requesting a secure computer address.” “[T]he claims themselves provide substantial guidance as to the meaning of particular claim terms” and “the context in which a term is used in the asserted claim can be highly instructive.” Phillips v. AWH Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005). At least based on the context of the claim, we cannot agree with Patent Owner that one of ordinary skill in the art would have understood that “recogniz[ing]” is required by claim 1 in the absence of a recitation of this alleged requirement. Based on the context of the claim, the Specification, and the prosecution history, claim 1 does not require “recogniz[ing]” as argued by Patent Owner. The Specification describes an “SDNS 313” that “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.” Ex. 1001, 47:15–18. This disclosure comes closest to aligning with the claim term, “secure domain service” (i.e., an SDNS as set forth in the disclosure). Patent Owner does not point the panel to a disclosure in the Specification that clearly supports the requirement of an SDNS to “recognize that the query message is requesting a secure computer address.” Hence, further based on the context of the Specification, we cannot agree with Patent Owner that one of ordinary skill in the art would have understood that “recogniz[ing]” is required by claim 1 in the absence of such a disclosure in the Specification of this alleged requirement.” slip op. at 5
- Claim Construction › Threshold & procedure › Whether a term needs construction (O2 Micro)No construction neededDecided for patent owner
“Patent Owner argues that one of ordinary skill in the art would have understood the term “tunnel packeting” to mean “forming a packet to be transmitted that contains data structured in one protocol format within the format of another protocol.” PO Resp. 19. However, Patent Owner does not demonstrate sufficiently that the construction of “tunnel packeting” will bear on the outcome of the issues in this inter partes review. Hence, we decline to modify our construction of this term.” slip op. at 7
- Novelty / Anticipation (§102) › Anticipation standard (single reference, every element)UnpatentableUnpatentable
“Claim 1 recites sending a message from a first network device for an address for a second network device and, in response, receiving at the first network device the address for the second network device. Kiuchi discloses that a client-side proxy “asks the C-HTTP name server whether it can communicate with the host” and that, in response, the C-HTTP name server examines “the requested server-side proxy.” In response to the request from the client-side proxy, the client-side proxy (i.e., “first network device”) receives “the IP address and public key of the server-side proxy.” Ex. 1004, 65. In other words, Kiuchi discloses a first network device (or a client-side proxy) sending a message to the C-HTTP name server (or secure domain service) to request a secure network address (e.g., an “IP address and public key”) for a second network device (i.e., server-side proxy) and then, in response, receiving at the client-side proxy the requested secure network address for the second network device (i.e., “the IP address and public key of the server-side proxy”). Patent Owner does not demonstrate persuasively a difference between Kiuchi and the claimed invention. Patent Owner argues that Kiuchi discloses that the client-side proxy sends a request for a network address for the “origin server” but not for the server-side proxy. However, Kiuchi discloses that in response to the request to communicate with “the host,” the name server examines “the requested server-side proxy” and returns “the IP address . . . of the server-side proxy.” Ex. 1004, 65 (emphasis added). Thus, contrary to Patent Owner’s contention, “the host” of Kiuchi corresponds to the “server-side proxy” (or second network device, as recited in claim 1).” slip op. at 11
Patent outcomesUS 7,987,274 unpatentableClaim construction§ 102 anticipation§ 103 obviousnesscites PhillipsPatents in suitUS 7,987,274 - Apple Inc. v. Virnetx Inc.All claims unpatentablePTAB · Jul 29, 2015 · IPR2014-00484 · APJ Stephen C Siu · IPR · Final written decision
Claims 1–5, 7, 8, 10, 12, 15, and 17 are unpatentable: claims 1–4, 7, 8, 10, 12, 15, and 17 over Kiuchi; claim 5 over combinations including Kiuchi and Lindblad.
RulingsFinal written decision- Claim Construction › Threshold & procedure › Whether a term needs construction (O2 Micro)Term construed petitioner constructionDecided for petitioner
“the term “secure domain (name) service,” in light of the Specification, to require “recogniz[ing] that a query message is requesting a secure computer address.” PO Resp. 16. Petitioner proposes that a secure domain (name) service (SDNS) should be construed as “[a] service that can resolve secure computer network addresses for a secure domain name for which a conventional domain name service [(“DNS”)] cannot resolve addresses.” See Pet. 13; PO Resp. 15 (discussing Petitioner’s proposed construction). Claim 1, for example, recites sending a query message to “a secure domain service” requesting a secure network address and receiving “a response message from the secure domain name service containing the secure network address.” Claim 1 does not recite “recogniz[ing] that the query message is requesting a secure computer address.” “[T]he claims themselves provide substantial guidance as to the meaning of particular claim terms” and “the context in which a term is used in the asserted claim can be highly instructive.” Phillips v. AWH Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005). At least based on the context of the claim, we cannot agree with Patent Owner that one of ordinary skill in the art would have understood that “recogniz[ing]” is required by claim 1 in the absence of a recitation of this alleged requirement. Based on the context of the claim, the Specification, and the prosecution history, claim 1 does not require “recogniz[ing]” as argued by Patent Owner. The Specification describes an “SDNS 313” that “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.” Ex. 1001, 47:15–18. This disclosure comes closest to aligning with the claim term, “secure domain service” (i.e., an SDNS as set forth in the disclosure). Patent Owner does not point the panel to a disclosure in the Specification that clearly supports the requirement of an SDNS to “recognize that the query message is requesting a secure computer address.” Hence, further based on the context of the Specification, we cannot agree with Patent Owner that one of ordinary skill in the art would have understood that “recogniz[ing]” is required by claim 1 in the absence of such a disclosure in the Specification of this alleged requirement.” slip op. at 5
- Claim Construction › Intrinsic evidence (Phillips canons) › Plain and ordinary meaning to a POSITATerm construed board ownDecided for petitioner
“domain service” requesting a secure network address and receiving “a response message from the secure domain name service containing the secure network address.” Claim 1 does not recite “recogniz[ing] that the query message is requesting a secure computer address.” “[T]he claims themselves provide substantial guidance as to the meaning of particular claim terms” and “the context in which a term is used in the asserted claim can be highly instructive.” Phillips v. AWH Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005). At least based on the context of the claim, we cannot agree with Patent Owner that one of ordinary skill in the art would have understood that “recogniz[ing]” is required by claim 1 in the absence of a recitation of this alleged requirement. Based on the context of the claim, the Specification, and the prosecution history, claim 1 does not require “recogniz[ing]” as argued by Patent Owner. The Specification describes an “SDNS 313” that “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.” Ex. 1001, 47:15–18. This disclosure comes closest to aligning with the claim term, “secure domain service” (i.e., an SDNS as set forth in the disclosure). Patent Owner does not point the panel to a disclosure in the Specification that clearly supports the requirement of an SDNS to “recognize that the query message is requesting a secure computer address.” Hence, further based on the context of the Specification, we cannot agree with Patent Owner that one of ordinary skill in the art would have understood that “recogniz[ing]” is required by claim 1 in the absence of such a disclosure in the Specification of this alleged requirement.” slip op. at 5
- Novelty / Anticipation (§102) › Anticipation standard (single reference, every element)UnpatentableUnpatentable
“Claim 1 recites sending a message from a first network device for an address for a second network device and, in response, receiving at the first network device the address for the second network device. Kiuchi discloses that a client-side proxy “asks the C-HTTP name server whether it can communicate with the host” and that, in response, the C-HTTP name server examines “the requested server-side proxy.” In response to the request from the client-side proxy, the client-side proxy (i.e., “first network device”) receives “the IP address and public key of the server-side proxy.” Ex. 1004, 65. In other words, Kiuchi discloses a first network device (or a client-side proxy) sending a message to the C-HTTP name server (or secure domain service) to request a secure network address (e.g., an “IP address and public key”) for a second network device (i.e., server-side proxy) and then, in response, receiving at the client-side proxy the requested secure network address for the second network device (i.e., “the IP address and public key of the server-side proxy”). Patent Owner does not demonstrate persuasively a difference between Kiuchi and the claimed invention. Patent Owner argues that Kiuchi discloses that the client-side proxy sends a request for a network address for the “origin server” but not for the server-side proxy. However, Kiuchi discloses that in response to the request to communicate with “the host,” the name server examines “the requested server-side proxy” and returns “the IP address . . . of the server-side proxy.” Ex. 1004, 65 (emphasis added). Thus, contrary to Patent Owner’s contention, “the host” of Kiuchi corresponds to the “server-side proxy” (or second network device, as recited in claim 1). Patent Owner also argues that Kiuchi fails to disclose an access request message, as recited in claim 1. In particular, Patent Owner argues that Kiuchi discloses a “user agent” sending a query message for a secure domain service, rather than a “first network device” (i.e., a client-side proxy of Kiuchi) sending a request to a secure domain service. PO Resp. 36 (citing Ex. 2041 ¶ 42 (“Declaration of Fabian Monrose, Ph.D.” or “Monrose Dec.”). We are not persuaded by Patent Owner’s arguments. Dr. Monrose testifies that Kiuchi discloses an “HTTP/1.0 message [that] is sent ‘from the user agent’ and reaches neither the host/origin server nor the server-side proxy.” Ex. 2041 ¶ 42. However, as previously discussed, Kiuchi discloses a step of “sending . . . requests to the server-side proxy” in which “a client-side proxy forwards HTTP/1.0 requests from the user agent” to the server-side proxy. Ex. 1004, 66. Neither Patent Owner nor Patent Owner’s declarant (Dr. Monrose) explains sufficiently how an “HTTP/1.0 request” that is “forwarded” by a client-side proxy to a server-side proxy fails to reach the server-side proxy in Kiuchi or that the forwarded request in Kiuchi is somehow diverted prior to reaching the server-side proxy and does not arrive at its intended destination. Patent Owner also argues that Kiuchi discloses that the client-side proxy “dispatches a new C-HTTP request” but Kiuchi fails to disclose that the client-side proxy sends “an HTTP/1.0 request.” PO Resp. 37. First, we note that claim 1 recites “sending an access request message.” Claim 1 does not recite or otherwise require “sending an HTTP/1.0 request.” For at least this reason, we are not persuaded by Patent Owner’s argument. Also, as previously discussed, Kiuchi discloses “sending . . . requests to the server-side proxy” in which “a client-side proxy forwards HTTP/1.0 requests” to the server-side proxy. Ex. 1004, 66. Patent Owner does not demonstrate persuasively a material difference between the client-side proxy “sending” a request to a server-side proxy and a client-side proxy “forwarding” a request to a server-side proxy. In both cases, a request is transmitted from the client-side proxy to the server-side proxy. Patent Owner argues that Kiuchi discloses an “HTTP/1.0 request” that “is not an access request message [as recited in claim 1] at least because it does not seek any ‘communication, information, or services’ with the serverside proxy.” PO Resp. 38 (citing Ex. 2041 ¶¶ 44, 46). Kiuchi discloses a client-side proxy “[s]ending C-HTTP request to the server-side proxy” in which the “client-side proxy forward HTTP/1.0 request” to the server-side proxy for communication and exchange of services between devices. Ex. 1004, 66. For example, Kiuchi discloses one example in which “patient information” is “transfer[red]” “among hospitals and related institutions.” Ex. 1004, 64. Patent Owner does not indicate sufficiently how Kiuchi’s request for communication between network devices for communication or information (e.g., patient information) exchange, for example, differs from a device seeking “any communication, information, or services.” Hence, to the extent that claim 1 requires seeking “any communication, information, or services,” we disagree with Patent Owner that Kiuchi fails to disclose this feature. PO Resp. 38. Patent Owner argues that Kiuchi fails to disclose sending an “HTTP/1.0 message” using a “virtual private network communication link.” PO Resp. 39. In particular, Patent Owner argues that Kiuchi discloses sending a message from a client-side proxy to a server-side proxy, which, according to Patent Owner, is “a point-to-point connection, not a network as claimed.” PO Resp. 39–40. Patent Owner also argues that Kiuchi fails to disclose sending a request “using a virtual private network communication link” because “the request [of Kiuchi] lacks the ‘network’ aspect of a VPN communication link and further because [Kiuchi merely discloses] a point-to-point message [instead of] a VPN communication link.” PO Resp. 42–43 (citing Ex. 2041 ¶ 52). Hence, Patent Owner argues that Kiuchi fails to disclose a “network.” We disagree with Patent Owner’s argument. For example, Kiuchi discloses one embodiment of the use of a C- HTTP name server (and client-side and server-side proxies) in “networks among hospitals and related institutions.” Ex 1004, 64. At least in view of this explicit disclosure of “networks,” we are not persuaded by Patent Owner that Kiuchi fails to disclose a “network.” Patent Owner argues that Kiuchi discloses sending an HTTP/1.0 request but that “the request must pass through both the client-side and server-side proxies to reach the origin server.” PO Resp. 41 (citing Ex. 2041 ¶ 51). According to Patent Owner, this indicates that “Kiuchi fails to disclose direct communications to any host server and any message from the client-side proxy . . . is not sent using a VPN communication link.” PO Resp. 41–42. Hence, Patent Owner argues that Kiuchi fails to disclose a “direct communication.” Claim 1, for example, recites sending an access request from a first” slip op. at 11
- Obviousness (§103) › Motivation to combine / reasonable expectation of successUnpatentableUnpatentable
“B. Kiuchi and Bhatti/Lindblad Regarding claims 1–5, 7, 8, 10, 12, 15, and 17, Patent Owner argues that it would not have been obvious to one of ordinary skill in the art to have combined the teachings of Kiuchi and Bhatti because Kiuchi discloses an “origin server” that, according to Patent Owner, corresponds to the “second network device,” as recited in claim 1, for example. PO Resp. 47–49. Even if the “origin server” of Kiuchi would somehow render the combination of Kiuchi and Bhatti improper, we need not consider Patent Owner’s argument further because, as previously discussed, Petitioner relies on the “server-side proxy” and not the “origin server” of Kiuchi as the recited second network device. Patent Owner also argues that Bhatti fails to disclose “using a virtual private network communication link.” PO Resp. 50. However, as discussed above, we agree with Petitioner that Kiuchi discloses this feature. No additional issues with respect to Bhatti or the Lindblad reference are identified. PO Resp. 50–51.” slip op. at 16
Patent outcomesUS 7,987,274 unpatentableClaim construction§ 102 anticipation§ 103 obviousnesscites PhillipsPatents in suitUS 7,987,274 - Apple Inc. v. Virnetx Inc.All claims unpatentablePTAB · Jul 29, 2015 · IPR2014-00483 · APJ Karl D Easthom · IPR · Final written decision
Claims 1, 7, 8, 10, 12, 13, 15, and 17 are unpatentable as anticipated by Provino; claims 2–5 and 18 are unpatentable as obvious over Provino with Kosiur and Xu, respectively.
RulingsFinal written decision- PTAB / AIA Trials › Joinder §315(c) / SAS all-or-nothingJoinder, grantedGranted
“Apple Incorporated (“Petitioner”) also filed a Petition (Paper 2) seeking an inter partes review of claims 1–5, 7, 8, 10, 12, 13, 15, 17, and 18 of the ’274 patent pursuant to 35 U.S.C. §§ 311–319 in Case IPR2014- 00483 (“’483 IPR”). Noting that Microsoft Corporation’s Petition and Apple Incorporated’s Petition were substantially identical in material aspects, the Board instituted an inter partes review of claims 1–5, 7, 8, 10, 12, 13, 15, 17, and 18, and joined IPR2014-00483 with IPR2014-00403 pursuant to 35 U.S.C. § 315(c). See ’483IPR, Paper 11, 6–9.2 Thereafter, pursuant to a settlement agreement, the present proceeding was terminated with respect to Microsoft Corporation only. Paper 38.” slip op. at 2
- Claim Construction › Intrinsic evidence (Phillips canons) › Prosecution history disclaimer / disavowalTerm construed petitioner constructionDisclaimer not foundDecided for petitioner
“proceeding somehow limits the claims here that Patent Owner otherwise could have moved to amend under a broadest reasonable construction, Patent Owner’s arguments were not “unambiguous,” and do not “call for the application of prosecution history disclaimer.” See PO Resp. 17–18. There was no “express disclaimer,” Bigio, 381 F.3d at 1325, or “unambiguous disavowal[],” Grober, 686 F.3d at 1341.” slip op. at 11
- Claim Construction › Threshold & procedure › Whether a term needs construction (O2 Micro)Term construed board ownDecided for petitioner
“As the latter two sentences show, the ’274 patent Specification describes placing field hopping data (i.e., an address hopping technique, see id. at 46:64–47:11), into a payload portion of a data packet. The Specification does not tie “tunneled” packets into a specific requirement that requires a change in formatting––above and apart from any protocol formatting or structural change that may happen to, or does, occur by placing one type of data field (header) into another type of data field (payload). After discussing the insertion of the field hopping data into the payload portion, the Specification then describes that these “modified message packets preferably conform to the UDP protocol,” or “[a]lternatively . . . can conform to the TCP/IP protocol or the ICPM protocol.” Id. at 50:30–35. In other words, if there is a change in a protocol in these disclosed examples––for example, from one protocol format to a UDP protocol format––any change appears to come in preferred embodiments and after the packets have been modified (i.e., tunneled). Accordingly, based on the foregoing discussion, we modify our construction as set forth in the Institution Decision, such that “tunnel packeting” means “placing data or information from one field, such as a header, into another packet field, such as a payload, wherein the two fields normally have different structures or formats, or placing data structured in one format within the format of another protocol.”” slip op. at 22
- Claim Construction › Intrinsic evidence (Phillips canons) › Plain and ordinary meaning to a POSITATerm construed board ownDecided for petitioner
“In any event, to the extent it is material, the ’274 patent Specification employs the term “user’s computer” in a “conventional scheme . . . shown in FIG 25. A user’s computer 2501 includes a client application 2504 (for example a web browser) . . . .” Ex. 1001, 38:61–63. Although Patent Owner refers to this “conventional” computer as “another embodiment,” the ’274 patent Specification disparages the “conventional architecture” that employs a user’s computer, because it is not secure enough. See Ex. 1001, 39:4–13; PO Resp. 21. In general, the ’274 patent Specification states that “[t]he present invention” involves a “client computer” with a “client application” that “communicates with a server.” See Ex. 1001, 7:40–44. This description of “[t]he present invention” does not mention a “user’s computer.” Therefore, the ’274 patent Specification does not repeatedly treat a “client computer” and a “user’s computer” as the same. The broadest reasonable construction of a client computer is a computer associated with a client.” slip op. at 23
Patent outcomesUS 7,987,274 unpatentableClaim construction§ 102 anticipation§ 103 obviousnesscites Phillips · KSRPatents in suitUS 7,987,274 - Medtronic, Inc. v. Robert Bosch Healthcare Systems, Inc.Rehearing deniedPTAB · May 22, 2015 · IPR2014-00488 · APJ Justin T Arbes · IPR · Rehearing
The Board denied Medtronic’s rehearing requests, leaving in place termination of the proceedings for failure to identify Cardiocom as a real party-in-interest.
RulingsRehearing decision- RehearingRehearing, deniedDenied
“Terminate should be modified lies with Medtronic, the party challenging the Decision. 37 C.F.R. § 42.71(d). A request for rehearing “must specifically identify all matters the party believes the Board misapprehended or overlooked, and the place where each matter was previously addressed.” Id. Medtronic makes six arguments in its Requests, which we address in turn.” slip op. at 2
- PTAB / AIA Trials › Real party in interest / privityRpi dispute resolved for patent ownerDecided for patent owner
“acting as a “proxy” for Cardiocom because we ignored Medtronic’s evidence that it exercises exclusive control over these proceedings. Req. Reh’g 7–8. To the contrary, we reviewed and evaluated all of the evidence submitted by the parties, including the declarations and documents again cited by Medtronic in its Requests for Rehearing. See Dec. 9–17. As explained in the Decision, whether a non-party is a real party-in-interest is a “highly fact-dependent question,” taking into account, among other things, the non-party’s “relationship with the petitioner,” the non-party’s “relationship to the petition itself, including the nature and/or degree of involvement in the filing,” and “the nature of the entity filing the petition.” Id. at 7–8 (citing the Office Patent Trial Practice Guide, 77 Fed. Reg. 48,756, 48,759–60 (Aug. 14, 2012)). No one fact was dispositive here; it was the totality of the evidence that showed Cardiocom to be a real party-in-interest, i.e., “the party that desires review of the patent[s].” Id. at 7, 16; Opp. 7–9. We did not ignore any evidence submitted by Medtronic. We drew inferences from the facts supported by the evidence and disagreed with Medtronic’s assessment of that evidence.” slip op. at 5
Discretionary denialPatents in suitUS 7,769,605 - Medtronic, Inc. v. Robert Bosch Healthcare Systems, Inc.Rehearing deniedPTAB · May 22, 2015 · IPR2014-00607 · APJ Justin T Arbes · IPR · Rehearing
The Board denied Medtronic’s rehearing requests, leaving in place termination of the proceedings because Cardiocom was an unnamed real party-in-interest.
RulingsRehearing decision- RehearingRehearing, deniedDenied
“Terminate should be modified lies with Medtronic, the party challenging the Decision. 37 C.F.R. § 42.71(d). A request for rehearing “must specifically identify all matters the party believes the Board misapprehended or overlooked, and the place where each matter was previously addressed.” Id. Medtronic makes six arguments in its Requests, which we address in turn.” slip op. at 2
- PTAB / AIA Trials › Real party in interest / privityDecided for patent owner
“acting as a “proxy” for Cardiocom because we ignored Medtronic’s evidence that it exercises exclusive control over these proceedings. Req. Reh’g 7–8. To the contrary, we reviewed and evaluated all of the evidence submitted by the parties, including the declarations and documents again cited by Medtronic in its Requests for Rehearing. See Dec. 9–17. As explained in the Decision, whether a non-party is a real party-in-interest is a “highly fact-dependent question,” taking into account, among other things, the non-party’s “relationship with the petitioner,” the non-party’s “relationship to the petition itself, including the nature and/or degree of involvement in the filing,” and “the nature of the entity filing the petition.” Id. at 7–8 (citing the Office Patent Trial Practice Guide, 77 Fed. Reg. 48,756, 48,759–60 (Aug. 14, 2012)). No one fact was dispositive here; it was the totality of the evidence that showed Cardiocom to be a real party-in-interest, i.e., “the party that desires review of the patent[s].” Id. at 7, 16; Opp. 7–9. We did not ignore any evidence submitted by Medtronic. We drew inferences from the facts supported by the evidence and disagreed with Medtronic’s assessment of that evidence.” slip op. at 5
NonePatents in suitUS 7,870,249 - Apple Inc. v. Virnetx Inc.All claims unpatentablePTAB · May 11, 2015 · IPR2014-00238 · APJ Stephen C Siu · IPR · Final written decision
Claims 1–3, 8–11, 14–17, 22–25, and 28–30 are unpatentable as anticipated by Wesinger; claims 4–7 and 18–21 are unpatentable over Wesinger and RFC 2543.
RulingsFinal written decision- Claim Construction › Threshold & procedure › Whether a term needs construction (O2 Micro)No construction neededOther
“Patent Owner argues that the term “secure communication link” must include encryption. See, e.g., PO Resp. 11, 13–19. Patent Owner, however, does not demonstrate sufficiently that the construction of this term impacts any issue in this proceeding. Therefore, we decline to construe this term. Virtual Private Network” slip op. at 3
- Novelty / Anticipation (§102) › Anticipation standard (single reference, every element)UnpatentableUnpatentable
“Patent Owner does not explain sufficiently a difference between the determination of whether a requested connection with a device is “allowed” or not and the determination of whether a device is “available” for a connection. One of ordinary skill in the art would have understood that if a connection with a virtual host is determined to be allowed if all rules are satisfied (as Wesinger discloses), then the virtual host would be determined to be “available” for the connection, the connection being formed with the virtual host based on the determination. Under an ordinary and customary construction of the term “available” as would have been understood by one of ordinary skill in the art in light of the Specification as being accessible for use, at hand, or usable,1 we do not discern a substantial difference between determining whether a device is allowed to connect (and connecting only if the device is allowed) and determining whether a device is available (or accessible for use, at hand, or usable) for a connection (and connecting only if the device is accessible for use, at hand, or usable). In both cases, a determination is made as to whether a connection will be made with a device and the connection is created based on this determination.” slip op. at 7
- Obviousness (§103) › Motivation to combine / reasonable expectation of successUnpatentableMotivation foundUnpatentable
“As previously discussed, Wesinger discloses a system in which a client sends a connection request for connection with a device and, if access is granted and “[i]f all the rules are satisfied, then the connection [with the device] is allowed.” Ex. 1008, 16:66–67. Petitioner does not indicate that Wesinger discloses a specific type of connection or session between devices. The RFC 2543 reference discloses a similar system in which a client “send[s] a request” in order to “establish . . . multimedia sessions or calls.” Ex. 1012 at 7, 13. Thus, RFC discloses that one of ordinary skill in the art would have known that different types of connections or sessions that may be established between devices include, for example, multimedia session or calls. We agree with Petitioner that the combination of such known features, performing their known functions, would have resulted in the mere predictable result of a system in which a connection or session is established between devices (Wesinger and RFC 2543), the connection or session being, for example, a multimedia session or call (RFC 2543).” slip op. at 12
- Expert testimonyOther
“C. Declaration of Michael Fratto Patent Owner argues that the Declaration of Michael Fratto Regarding U.S. Patent No. 8,504,697 (Ex. 1003) should not be given any weight. See, e.g., PO Resp. 1–8. We did not rely on the testimony of Mr. Fratto in this decision. Therefore, Patent Owner’s argument is moot.” slip op. at 14
Patent outcomesUS 8,504,697 unpatentableClaim construction§ 102 anticipation§ 103 obviousnessPatents in suitUS 8,504,697 - Apple Inc. v. Virnetx Inc.All claims unpatentablePTAB · May 11, 2015 · IPR2014-00237 · APJ Karl D Easthom · IPR · Final written decision
Claims 1–11, 14–25, and 28–30 are unpatentable: Beser anticipates claims 1, 3–11, 14–23, 25, and 28–30, and Beser with RFC 2401 renders all challenged claims obvious.
RulingsFinal written decision- Skill levelOther
- Claim Construction › Intrinsic evidence (Phillips canons) › Plain and ordinary meaning to a POSITATerm construed board ownDecided for petitioner
“Notwithstanding Patent Owner’s arguments that security requires encryption, the ’697 patent Specification states that “[a] tremendous variety of methods have been proposed and implemented to provide security and anonymity for communications over the Internet.” Ex. 1001, 1:35–37 (emphasis added). The ’697 patent Specification also describes data security and anonymity as counterpart safeguards against eavesdropping that may occur while two computer terminals communicate over the Internet. See id. at 1:38–54. Security, in one context, may refer to protection of the data itself, to preserve the secrecy of its contents, while anonymity refers to preventing an eavesdropper from discovering the identity of a participating terminal. See id. at 1:40–56. Further according to the ’697 patent Specification, the concept of security generally includes “two security issues,” address (anonymity) and data security, with “a desire[] for the communications to be secure, that is, immune to eavesdropping.” Id. at 1:42–43, 54–56.” slip op. at 5
- Novelty / Anticipation (§102) › Anticipation standard (single reference, every element)UnpatentableUnpatentable
“link” as required by claims 1 and 16. PO Resp. 49–52. As set forth above, according to Cisco and the claim construction, a secure communication link does not require encryption. Petitioner contends that even if a secure communication link requires encryption, Beser discloses at least some encryption for initial IP packets, and, in any case, also discloses anonymity. The record supports Petitioner on both theories, as we find above in Section II.A. (citing, e.g., Ex. 1009, 9:29–35, 11:22–25, 12:15–19 –16, Abstract). For example, regarding encryption, “[t]he IP 58 packets may require encryption or authentication to ensure that the unique identifier cannot be read on the public network 12.” Ex. 1009, 11:22–25. Patent Owner maintains that this encryption in Beser only occurs “in initiating the tunnel, not after the tunnel is established.” PO Resp. 49. Given our claim construction and the holding of Cisco we need not decide if initial encryption of address packets of Beser is sufficient to satisfy claims 1 and 16, or if Beser otherwise discloses more encryption, because claims 1 and 16 do not require any encryption.” slip op. at 20
- Obviousness (§103) › Motivation to combine / reasonable expectation of success › Teaching awayTeaching away not foundDecided for petitioner
“Petitioner replies by noting that Patent Owner’s declarant, Dr. Monrose, agreed, during his deposition, that “the implementation challenges that Beser identifies in using encryption can easily be navigated.” Pet. Reply 15 (citing Ex. 1083, 206:20–208:6). At the cited deposition passage, during questioning about teaching away in Beser, Dr. Monrose agrees that sending voice data with lower resolution would have been “conceivable” (Ex. 1083, 208:6), and that using a more powerful computer would constitute “one possible way” (id. at 207:7) to implement Beser’s system and use encryption. Therefore, as Petitioner contends, Dr. Monrose effectively concedes that Beser does not teach away from encryption when performed in higher power computers that do not accumulate a large number of packets at a node buffer––i.e., video or audio packets that capture a relatively lower resolution of voice or audio than other multimedia may capture. See Pet. Reply 15. In general, Beser’s system hides addresses on the public network, which “may increase the security of communication without an increased computational burden.” Ex. 1009, 3:5–9 (emphases added). Hiding, in packets, “private addresses” is a form of tunneling that provides anonymity. See Ex. 1009, Abstract (“hiding the identity”), 12:16–19 (negotiating the private addresses “through . . . device 30 to further ensure the anonymity of the telephony devices (24, 26)”). By “increasing” security without an increased computational burden, Beser’s tunnel techniques at least suggest adding a layer of security to known security methods––for example, by adding Beser’s anonymity method to the encryption of voice or audio data. Beser also describes prior art systems that encrypt data, hide addresses by encapsulating and encrypting them in the payloads of packets, or otherwise hide addresses by translating them. See Ex. 1009, 1:40–2:40.8 Beser describes potential hacking concerns due to accumulating a large number of packets at a source so that a hacker “may” be able to decrypt the packets and obtain source information. PO Resp. 57; Ex. 1009, 1:57, 54–58. However, as Dr. Monrose concedes and as Petitioner argues, lower resolution of audio or video data redounds to a lower accumulation of data packets. In addition, Beser does not describe a hacker problem as occurring when a scheme like Beser’s hides or encapsulates private address information inside a packet–a tunneling technique. Rather, in relation to Beser’s description of a prior art VPN (discussed further below), Beser only describes power concerns, instead of hacker concerns: “The tunneled IP packets . . . may need to be encrypted before the encapsulation in order to hide the source IP address. Once again, due to computer power limitations, this form of tunneling may be inappropriate for the transmission of multimedia or VoIP packets.” Ex. 1009, 2:12–17 (emphases added). 8 As discussed above, Beser specifically discloses encrypting at least some IP packets, although Patent Owner contends that this occurs only at tunnel initialization. See Ex. 1009, 11:22–25; PO Resp. 52–53 (citing Ex. 2025 ¶¶ 58).” slip op. at 38
Patent outcomesUS 8,504,697 unpatentableClaim construction§ 102 anticipation§ 103 obviousnessPatents in suitUS 8,504,697
Holdings, summaries, rulings, issues, outcomes, winners and claim constructions shown for a decision were generated by a large language model reading the opinion. They are a guide to the decision, not the decision. Confirm every one against the court's own text before relying on it. Outcomes read from the patent owner’s side. Party names are extracted from the decision and are missing on about 900 short Director denials and scans, which carry the trial number instead.