Uniloc 2017 LLCDownload PDFPatent Trials and Appeals BoardMay 6, 2020IPR2020-00101 (P.T.A.B. May. 6, 2020) Copy Citation Trials@uspto.gov Paper 10 571-272-7822 Date: May 6, 2020 UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD MICROSOFT CORPORATION, Petitioner, v. UNILOC 2017 LLC, Patent Owner. IPR2020-00101 Patent 8,495,359 B2 Before THOMAS L. GIANNETTI, TREVOR M. JEFFERSON, and CHRISTOPHER L. OGDEN, Administrative Patent Judges. OGDEN, Administrative Patent Judge. DECISION Denying Institution of Inter Partes Review 35 U.S.C. § 314 INTRODUCTION Petitioner Microsoft Corporation (“Microsoft”) filed a Petition for inter partes review (Paper 2, “Pet.”) of claims 1–15 of U.S. Patent No. 8,495,359 B2 (Ex. 1001, “the ’359 patent”). Patent Owner Uniloc 2017 LLC (“Uniloc”) filed a Preliminary Response (“Prelim. Resp.”). Paper 8. IPR2020-00101 Patent 8,495,359 B2 2 We may institute an inter partes review only if “the information presented in the petition . . . and any response . . . 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.” 35 U.S.C. § 314(a) (2018). Applying that standard, we do not institute an inter partes review, for the reasons explained below. BACKGROUND A. RELATED PROCEEDINGS The parties identify the following proceeding as relating to the ’359 patent: Uniloc 2017 LLC v. Microsoft Corporation, 8:19-cv-007831 (D.C. Cal. filed April 29, 2019). Pet. vi; Paper 6, 2. B. REAL PARTIES IN INTEREST Microsoft identifies only itself as the real party in interest. Pet. vi. Uniloc does not challenge that identification, and also only identifies itself as the real party in interest. Paper 6, 2. C. THE ’359 PATENT (EX. 1001) The ’359 patent relates to a system in which one computing device (the originator) sends an electronic communication to a recipient computing device, after encrypting the message using a key provided by a gateway server. Ex. 1001, 33–41. 1 Uniloc incorrectly lists the docket number as 8:19-cv-00873. Paper 6, 2. IPR2020-00101 Patent 8,495,359 B2 3 Figure 3B of the patent, reproduced below, depicts an embodiment of the invention: Figure 3B is a flowchart for a process (310) in which the gateway server interacts with the originator and receiver of the message. Ex. 1001, 6:60–61. Initially, in step 311, the gateway server receives and stores the network addresses and device identifiers of the devices it serves in the network. Id. at 6:61–64. Each device identifier “is generated by a process which operates on data indicative of the computing device’s configuration and hardware,” and “has a very high probability (e.g., greater than 99.999%) of being unique to the target device.” Id. at 4:3–5, 15–16. IPR2020-00101 Patent 8,495,359 B2 4 In step 313, the gateway server receives, from the originator, a request for an encryption key associated with the recipient device. Id. at 6:64–65. In step 315, if the intended recipient computer exists within the gateway server’s database, the gateway server generates an encryption key unique to the intended recipient. Id. at 6:64–7:1. In step 317, the gateway server then sends the encryption key to the originator. Id. at 7:10–13. The originator uses the key to encrypt the message, and then sends the secure message over the network to the recipient computer. Id. at 6:56–59. When the recipient computer receives the encrypted message, it generates its own encryption key using its stored device identifier, and uses that key to decrypt the message. Ex. 1001, 7:20–23. The recipient computer “may also take the additional step of querying the server to determine if the computer purporting to send the secure communication, i.e., the sending computer, did, in fact, request the encryption key.” Id. at 7:32–36; see also 7:13–15 (“[T[he server . . . may provide confirmations to the receiving computer that the sending computer requested and was sent the encryption key.”). According to the ’359 patent, “[s]uch confirmation aids in building trust that the communication actually originated from the sending computer.” Id. at 7:15–17. IPR2020-00101 Patent 8,495,359 B2 5 D. CHALLENGED CLAIMS AND ASSERTED GROUND OF UNPATENTABILITY Microsoft’s sole ground for the inter partes review is summarized in the following table: Claims Challenged 35 U.S.C. § References 1–15 1032 Olkin,3 Kim4 Pet. 2. Microsoft argues that claims 1–15 of the ’359 patent are unpatentable as obvious over Olkin in view of Kim. See Pet. 2, 11–40. Independent claim 1, which follows, exemplifies the invention: [1.1] 1. A system for securing an electronic communication, the system comprising: [1.2] a gateway server configured to: receive and store a device identifier and a network address from a first computing device, wherein the device identifier is generated by the first computing device from a combination of user-configurable and non-user-configurable parameters of the first computing device and uniquely identifies the first computing device, and wherein the network address is associated with the first computing device; [1.3] receive from a second computing device the network address for the first computing device and an encryption key request; [1.4] derive an encryption key from the device identifier for the first computing device; 2 Because the filing date of the ’359 patent is before March 16, 2013, we apply the version of 35 U.S.C. § 103 that existed prior to the Leahy–Smith America Invents Act. See Pub. L. No. 112-29, § 3(n)(1), 125 Stat. 284, 293 (2011). 3 Olkin et al., US 7,376,835 B2, issued May 20, 2008 (Ex. 1003) (“Olkin”). 4 Kim et al., US 2009/0055648 A1, published Feb. 26, 2009 (Ex. 1004) (“Kim”). IPR2020-00101 Patent 8,495,359 B2 6 [1.5] send the encryption key to the second computing device, and [1.6] confirm to the first computing device that the encryption key was requested by the second computing device and was sent to the second computing device. Ex. 1001, 8:40–60 (Microsoft’s reference numbers added). Claims 6 and 11 are also independent. See id. at 9:6–24, 10:1–23. Claims 2–5 depend from claim 1, claims 7–10 depend from claim 6, and claims 12–15 depend from claim 11. See id. at 8:61–10:35. Microsoft relies on the declaration of Henry Houh, Ph.D, Ex. 1008. Uniloc does not presently contest Dr. Houh’s qualification to provide expert testimony on the subject matter of his declaration, and we have considered his testimony for the purpose of this decision. Uniloc did not provide a rebuttal expert at this stage of the proceeding. ANALYSIS Microsoft’s sole ground for seeking inter partes review of the ’359 patent is that claims 1–15 would have been obvious over Olkin in view of Kim. See Pet. 2. A claim is unpatentable for obviousness under 35 U.S.C. § 103 if the differences between the claimed subject matter and the prior art are “such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains.” KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007). We typically consider “whether there was an apparent reason to combine the known elements in the fashion claimed by the patent at issue.” Id. at 418 (citing In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006)). A sufficient ground for obviousness in a petition must “articulate specific IPR2020-00101 Patent 8,495,359 B2 7 reasoning, based on evidence of record, to support the legal conclusion of obviousness.” In re Magnum Oil Tools Int’l, Ltd., 829 F.3d 1364, 1380 (Fed. Cir. 2016) (citing KSR, 550 U.S. at 418); see also 35 U.S.C. § 322(a)(3) (2018); 37 C.F.R. §§ 42.22(a)(2), 42.104(b)(4) (2019). The obviousness inquiry requires an analysis of underlying factual considerations including (1) the scope and content of the prior art, (2) any differences between the claimed subject matter and the prior art, (3) the level of skill in the art, and (4) any objective indicia of obviousness or non- obviousness (i.e., secondary considerations) that may be in evidence.5 See Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966). Based on the evidence and arguments presented in the Petition, and in light of Uniloc’s Preliminary Response, we are unable to conclude that Microsoft has demonstrated a reasonable likelihood of success on its obviousness ground, for the reasons discussed below. A. LEVEL OF ORDINARY SKILL IN THE ART The level of ordinary skill in the pertinent art at the time of the invention is one of the factual considerations relevant to obviousness. See Graham, 383 U.S. at 17. It is also pertinent to interpreting the patent claims, see Phillips v. AWH Corp., 415 F.3d 1303, 1312–13 (Fed. Cir. 2005) (en banc). To assess the level of ordinary skill, we construct a hypothetical “person of ordinary skill in the art,” from whose vantage point we assess obviousness and claim interpretation. See In re Rouffet, 149 F.3d 1350, 1357 5 Because neither party has presented evidence of objective indicia of obviousness or non-obviousness, we do not address this consideration in our decision. See Pet. 40 (stating that Microsoft is unaware of any secondary considerations of non-obviousness). IPR2020-00101 Patent 8,495,359 B2 8 (Fed. Cir. 1998). This legal construct “presumes that all prior art references in the field of the invention are available to this hypothetical skilled artisan.” Id. (citing In re Carlson, 983 F.2d 1032, 1038 (Fed. Cir. 1993)). Citing testimony of Dr. Houh, Microsoft argues that a person of ordinary skill in the art “would have a bachelor’s degree in computer science, electrical and/or computer engineering, or equivalent training, and two years of experience in computer networking and information security.” Pet. 9 (citing Ex. 1008 ¶ 43 (Dr. Houh’s testimony to that effect)). For the purpose of its Preliminary Response, Uniloc does not dispute Microsoft’s assertion. See Prelim. Resp. 10–11. We find that Microsoft’s proposed level of ordinary skill is consistent with the teachings of the ’359 patent and the cited prior art. See Okajima v. Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001) (holding that the prior art itself may provide evidence as to the appropriate level of ordinary skill). Therefore, we adopt Microsoft’s uncontested formulation as the level of ordinary skill for this decision. B. CLAIM CONSTRUCTION The Board interprets patent claims using the same claim construction standard that would be used to construe the claims in a civil action under 35 U.S.C. § 282(b). 37 C.F.R. § 42.100(b) (2019). Under this standard, we generally give claim terms their “ordinary and customary meaning . . . as understood by one of ordinary skill in the art and the prosecution history pertaining to the patent.” Id. The ordinary and customary meaning is the meaning the claim language would have to a person of ordinary skill at the IPR2020-00101 Patent 8,495,359 B2 9 time of the invention, in the context of the entire patent including the specification. See Phillips, 415 F.3d at 1312–13. Microsoft contends that the claims of the ’359 patent “do not require proposed constructions that differ from the claim language in order for the Board to compare the prior art to the claims.” Pet. 9. Likewise, Uniloc “contends that no claim terms require specific construction to resolve the unpatentability issues presented” in the Petition. Prelim. Resp. 10. In light of the parties’ arguments and evidence, we agree with the parties that it is unnecessary to expressly construe any claim terms for our determination of whether to institute an inter partes review. See Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017) (“[W]e need only construe terms ‘that are in controversy, and only to the extent necessary to resolve the controversy.’” (quoting Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999))). Nevertheless, our interpretation of the ’359 patent claims is informed by the disclosure and prosecution history, and we will discuss our interpretation of pertinent claim terms in the context of our analysis in the section below. A. COMPARISON OF THE CHALLENGED CLAIMS WITH THE PRIOR ART 1. Overview of Olkin Olkin describes a communication system for sending and receiving email messages and other communications via transactions with a “key server.” Pet. 12 (citing Ex. 1003, 21:27–43, 21:57–58); Prelim. Resp. 12 (citing Ex. 1003, 8:44–56). IPR2020-00101 Patent 8,495,359 B2 10 Olkin’s Figure 11, reproduced below, illustrates an example of such a system: Figure 11 is a block diagram with four basic components: communication originator 314, communication recipient 316, key server 320, and authentication authority 318. Ex. 1003, 26:38–41. Originator 314 and Recipient 316 will at some point independently authenticate themselves with authentication authority 318, and receive authentication assertion 322, which they will use to authenticate themselves with key server 320. Id. at 26:42– 55. Olkin’s system uses “conversation keys.” Pet. 12. These are symmetric keys that “flow[] from a single source to one or more destinations.” Ex. 1003, 21:48–50. When originator 314 wishes to obtain a conversation key in order to send secure messages to one or more recipients including recipient 316, it contacts key server 320 and provides it with IPR2020-00101 Patent 8,495,359 B2 11 authentication assertion 322 and attributes 326 for intended communication 324. Id. at 26:56–60. These attributes 326 may include a list of intended recipients 316 for the communication. Id. at 26:60–62. Key server 320 confirms the originator’s authentication assertion 322 and creates “a key 330 suitable to encrypt the communication 324,” which it sends back to originator 314 for use in encrypting the communication. Id. at 63–67. Alternatively to having key server 320 create and send an encryption key to the originator at its request, originator 314 “can instead send the key 330 to the key server 320 and ask it to associate that key 330 with a resource ID 328”; the originator can then use its own key to encrypt future communications within the system. See id. at 27:1–3; see also id. at 22:37– 38 (the key server either “creates the keys . . . or it can receive them from source participants.”). When recipient 316 receives an encrypted message from originator 314, recipient 316 can ask key server 320 (using its authentication assertion 322 and resource ID 328) for a key for decrypting the message. Ex. 1003, 27:15–21. Key server 320 verifies authentication assertion 322 and also checks that recipient 316 “is an intended one for the communication 324 that the resource ID 328 specifies, using the list of intended recipients 316 that the originator 314 previously provided in the attributes 326.” Id. at 27:21– 26. Key server 320 then sends the key to recipient 316 for use in decrypting the communication. Id. at 27:30–31. 2. Overview of Kim Kim describes a scheme for “identity based encryption (IBE).” Ex. 1004 ¶ 23. The scheme allows “any string to be used as a valid public key.” IPR2020-00101 Patent 8,495,359 B2 12 Id. ¶ 24. The key may therefore include a string representing an identity, such as an email address, of the intended recipient. Id. In an exemplary embodiment, an intended recipient of a communication transmits “seed information” to an originating device, which may include information about the device’s hardware, as well as user credentials. Id. at ¶¶ 28, 31–33. The originating device generates a public encryption key for encrypting its communications, using the predetermined seed information and the user credentials. Id. ¶ 31. To decrypt these messages, the recipient device generates and keeps a “secret key based on the seed information and the credential according to the IBE scheme.” Id. ¶ 34. 3. Claim 1 (a) Microsoft’s Arguments Microsoft asserts that the combination of Olkin and Kim teaches every limitation of claim 1, and that it would have been obvious to combine the two references in the way recited in claim 1. See Pet. 11–29. According to Microsoft, Olkin discloses “conversation keys,” but does not explain how they are generated. Pet 12–13. Therefore, Microsoft argues that a person of ordinary skill in the art would have naturally looked to Kim, which discloses details of generating keys meeting the limitations of claim 1. Id. at 13–14. The preamble (1.1) recites “[a] system for securing an electronic communication.” Ex. 1001, 8:40. This system includes three devices: a “gateway server,” a “first computing device” (the recipient), and a “second computing device (the originator). See Ex. 1001, 8:40–53; see also Prelim. Resp. 3–4 (explaining that the first computing device is the recipient, and the IPR2020-00101 Patent 8,495,359 B2 13 second computing device is the originator). As recited in the claim, the gateway server is “configured to” perform a series of steps. Ex. 1001, 8:42. Microsoft identifies these three devices in Olkin’s Figure 11 and supporting text. See Pet. 15–16. Limitations 1.2 and 1.3 recite steps in which the gateway server does the following: (1.2) generates a “device identifier” based on user- configurable and non-user-configurable parameters, and (1.3) receives an “encryption key request” from the second computing device (the originator). See Ex. 1001, 8:43–53. Microsoft argues that a combination of Olkin and Kim meets limitation 1.2, and that Olkin alone teaches limitation 1.3. Id. at 15–23.6 Limitation 1.4 requires that the gateway server be configured to “derive an encryption key from the device identifier for the first computing device.” Ex. 1001, 8:54–55. Microsoft concedes that Olkin does not explicitly disclose deriving an encryption key from a device identifier, but argues that a person of ordinary skill in the art “would understand this limitation to be taught by the combination of Olkin and Kim.” Pet. 24. According to Microsoft, “Kim teaches that an encryption key can be generated using seed information (which includes non-configurable information . . .) plus personal information (configurable).” Id. (emphasis omitted). Thus, Microsoft argues that “using the teachings of Kim, a [person of ordinary skill in the art] implementing Olkin would use both configurable 6 In its Preliminary Response, Uniloc does not specifically dispute Microsoft’s contentions for the preamble 1.1 and limitations 1.2–1.3. See Prelim. Resp. 21–30 (arguing only with respect to limitations 1.4–1.6). IPR2020-00101 Patent 8,495,359 B2 14 and non-configurable data to generate an encryption key.” Id. at 25 (citing Ex. 1008 ¶ 66). Limitation 1.5 requires that the gateway server be configured to “send the encryption key to the second computing device.” Ex. 1001, 8:56. Microsoft argues that “Olkin satisfies this limitation” because as shown in Olkin’s Figure 11 (reproduced above), “the generated encryption key is sent back to the originator (the second computing device).” Pet. 26 (quoting Ex. 1003, 26:63–67) (citing Ex. 1008 ¶ 67). Limitation 1.6 requires that the gateway server be configured to “confirm to the first computing device that the encryption key was requested by the second computing device and was sent to the second computing device.” Ex. 1001, 8:58–60. Microsoft argues that “Olkin in combination with Kim satisfies this limitation.” Pet. 26. According to Microsoft, the recited confirmation step takes place in Olkin’s disclosure when the recipient device obtains a key from the key server. Pet. 27 (quoting Ex. 1003, 27:15–30). Microsoft contends that when the recipient asks for a key to decrypt a message from the originator, “[t]he key server checks that the recipient was intended to receive the message by using the list previously provided by the originator (the second computing device).” Id. (citing Ex. 1003, 27:22–26). Thus, according to Microsoft, “by sending the key to the recipient, the key server (gateway server) is confirming that the encryption key was originally requested by and sent to the originator.” Id. (citing Ex. 1003, 27:21–30; Ex. 1008 ¶ 69). Microsoft notes that Olkin’s key server performs checks to verify that the communication is authorized, and “[i]f all the checks do not pass, the key server would not send the encrypted key IPR2020-00101 Patent 8,495,359 B2 15 back to the recipient for decryption.” Id. at 28 (citing Ex. 1003, 27:21–30; Ex. 1008 ¶ 71). (b) Discussion Among other arguments, Uniloc contends that the combination of Olkin and Kim fails to satisfy the confirmation step recited in limitation 1.6. See Prelim. Resp. 25–30. According to Uniloc, Olkin only teaches that key server 320 provides a decryption key to recipient 316, but “[t]here exists no disclosure within the entirety of Olkin that the key server 320 confirms in any manner with the recipient 316 that the key 330 was provided to the originator 314.” Id. at 28. Uniloc argues that Microsoft’s argument that confirmation takes place when key server 320 provides the recipient a key “is conclusory in that it attempts to read into the disclosure of Olkin that which was never intended to be taught or suggested by Olkin.” Id. at 29. Uniloc also contends that Olkin does not implicitly teach a confirmation step, because “sending the key to the recipient does not implicitly identify any of a myriad of operations that could have possibly been performed by either of the originator and/or the key server.” Id. We agree with Uniloc that Olkin does not explicitly or implicitly disclose that its key server is configured to confirm to the recipient device “that the encryption key was requested by the [originator] and was sent to the [originator].” Ex. 1001, 8:58–60. First, the mere fact that Olkin’s key server gives a key to the recipient for decrypting a message does not necessarily mean that the key server sent the originator an encryption key at its request. Although, in one embodiment, Olkin’s key server provides a key upon request from an originator, Olkin also teaches that originator 314 “can instead send the key 330 to the key IPR2020-00101 Patent 8,495,359 B2 16 server 320 and ask it to associate that key 330 with a resource ID 328,” which the originator can then use to encrypt future communications. Ex. 1003, 27:1–3; see also id. at 22:37–38 (the key server either “creates the keys . . . or it can receive them from source participants.”). In this latter case, originator 314 need never have requested an encryption key, and key server 320 need never have sent an encryption key back to the originator. Thus, the mere fact that Olkin’s key server performs all checks and successfully provides a key to the recipient for decrypting a message does not necessarily mean that “the encryption key was requested by the second computing device and was sent to the second computing device,” as claim 1 requires. Ex. 1001, 8:58–60. Second, even if a recipient in Olkin’s system were able to reliably infer, from the key server’s actions in sending it a key, that the key server had sent an encryption key to the message originator at the originator’s request, the specification of the ’359 patent, and its prosecution history, do not support Microsoft’s theory that such an inference may constitute the act of “confirm[ing]” as recited in limitation 1.6. Claim 1 recites “a gateway server configured to” perform the confirmation step. Ex. 1001, 8:42, 58–60. Thus, it is the gateway server—not the recipient—that must be configured to perform the confirmation step in its entirety. The confirmation step must be more than simply an inference that the recipient makes based on its understanding of how the key server typically operates. The prosecution history of the ’359 patent supports this understanding that the “confirm” step is an independent affirmative action by the gateway server, and more than simply an inference by the recipient. During IPR2020-00101 Patent 8,495,359 B2 17 prosecution, the inventor added limitation 1.6 to distinguish over a prior art reference. Ex. 1002, 45–46. According to the inventor’s counsel, a recipient computing device may receive a communication that contains the correct encryption key, but for security purposes the recipient computing device may wish to verify that the sending computing device was originally authorized to receive the encryption key and in fact obtained the encryption key legitimately via the trusted gateway server. The confirmation step is therefore an independent verification step for authenticating the communication. Ex. 1002, 46 (emphasis added). Finally, Microsoft has not sufficiently explained why a person of ordinary skill in the art would have modified Olkin’s system by adding an independent verification step. Olkin uses “conversation keys,” which are associated with a flow of messages “from a single source to one or more destinations.” Ex. 1003, 21:48–50. In Olkin’s system, the originator sends the messages to members of a recipient list, but the intended recipients on that list need not be authenticated before, or even after, the originator sends the message. See Ex. 1003, 9:55–60 (an intended recipient need not be registered with the system when the originator requests the key); id. at 10:3– 7 (alternatively, the security server “need not be concerned with whether the receivers . . are registered”). Microsoft has not adequately explained why, in Olkin’s system, where messages may be broadcast to multiple recipients before those recipients are even registered, a person of ordinary skill in the art would have had reason to independently verify to the recipients that the originator asked for, and was sent, an encryption key. For the above reasons, we determine that Microsoft has not adequately shown that Olkin teaches or suggests limitation 1.6 of claim 1. Microsoft does not point to any passage in Kim that would supply the IPR2020-00101 Patent 8,495,359 B2 18 missing teaching. See Pet. 26–29. Nor do Microsoft’s arguments regarding limitations 1.1–1.5 demonstrate that the combination of Olkin and Kim teaches limitation 1.6. See id. at 11–26. Thus, we determine that Microsoft has not demonstrated a reasonable likelihood of prevailing in showing that claim 1 would have been obvious over Olkin in combination with Kim. 4. Claim 2–15 Like claim 1, independent claims 6 and 11 both include a “confirmation” step similar to limitation 1.6. See Ex. 1001, 9:22–24 (“confirming to the first computing device that the encryption key was requested by the second computing device and was sent to the second computing device”); see id. at 10:16–18 (“querying, by the recipient computing device, the gateway server for confirmation that the sending computing device requested the first encryption key”). Microsoft’s argument regarding limitation 1.6 is identical to the argument for the corresponding limitation in claim 6, see Pet. 26–29, and substantially the same as the argument for the corresponding limitation in claim 11, see id. at 35–37. The remaining claims 2–5, 7–10, and 12–15 depend from claims 1, 6, or 11, and thus include the “confirmation” step of the base claims. Microsoft’s analysis only addresses the added limitations of each dependent claim, and does not provide further argument or evidence relevant to limitation 1.6 or the corresponding limitations in claims 6 and 11. See Pet. 29–32, 38–40. Thus, for the same reasons given above as to claim 1, we determine that Microsoft has not sufficiently shown that claims 2–15 would have been obvious over Olkin in combination with Kim. See In re Fine, 837 F.2d 1071, IPR2020-00101 Patent 8,495,359 B2 19 1076 (Fed. Cir. 1988) (“Dependent claims are nonobvious under section 103 if the independent claims from which they depend are nonobvious.”) B. CONCLUSION After considering the evidence and arguments presented in the Petition and Preliminary Response, we determine that Petitioner has not demonstrated a reasonable likelihood of prevailing in proving that at least one challenged claim of the ’359 patent is unpatentable. Therefore, we deny the Petition. ORDER In consideration of the foregoing, it is ORDERED that the Petition is denied, and no trial is instituted. IPR2020-00101 Patent 8,495,359 B2 20 For PETITIONER: Todd M. Siegel Andrew M. Mason Robert F. Scotti Joseph T. Jakubek KLARQUIST SPARKMAN, LLP todd.siegel@klarquist.com andrew.mason@klarquist.com robert.scotti@klarquist.com joseph.jakubek@klarquist.com For PATENT OWNER: Ryan Loveless Brett Mangrum James Etheridge Jeffrey Huang ETHERIDGE LAW GROUP ryan@etheridgelaw.com brett@etheridgelaw.com jim@etheridgelaw.com jeff@etheridgelaw.com Copy with citationCopy as parenthetical citation