XRS Corporation

Patent Trials and Appeals Board

Dec 14, 2021

IPR2021-00325 (P.T.A.B. Dec. 14, 2021)

Trials@uspto.gov Paper 13 571-272-7822 Entered: December 14, 2021 UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ PLATFORM SCIENCE, INC., Petitioner, v. XRS CORPORATION, Patent Owner. ____________ IPR2021-00325 Patent 10,255,575 B2 ____________ Before KEN B. BARRETT, NEIL T. POWELL, and FREDERICK C. LANEY, Administrative Patent Judges. POWELL, Administrative Patent Judge. DECISION Denying Petitioner’s Request for Rehearing of Decision Denying Institution 37 C.F.R. § 42.71(d) IPR2021-00325 Patent 10,255,575 B2 2 I. INTRODUCTION Petitioner Platform Science, Inc. filed a Request for Rehearing under 37 C.F.R. 42.71(d). Paper 12 (“Request” or “Req. Reh’g”). The Request for Rehearing seeks reconsideration of our decision (Paper 9, “Decision” or “Dec.”) denying institution of inter partes review of claims 1-24 of U.S. Patent No. 10,255,575 B2 (“the ’575 patent,” Ex. 1001). The Petition asserts that the challenged independent claims would have been obvious over Nehowig,1 DOT Regulations,2 and Fedorchuk.3 Paper 2 (“Pet.”), 6. In our Decision, we determined that Petitioner failed to explain adequately and persuasively why a person of ordinary skill in the art would have had a reason to configure the system in the manner proposed by Petitioner. See Dec. 16-27. We concluded that Petitioner had not demonstrated that there is a reasonable likelihood of establishing the unpatentability of at least one of the challenged claims of the ’575 patent. Id. at 27-29. As we explain below, we have considered the arguments presented by Petitioner in its Request for Rehearing, but we discern no reason to modify our Decision. As a result, we deny Petitioner’s Request for Rehearing. II. STANDARD OF REVIEW A party requesting rehearing bears the burden of showing that the decision should be modified. 37 C.F.R. § 42.71(d). “The request must specifically identify all matters the party believes the Board misapprehended or overlooked, and the place where each matter was previously addressed in a motion, an opposition, or a reply.” Id. When rehearing a decision on a 1 U.S. Pat. App. No. 2012/0194679 A1, pub. Aug. 2, 2012 (Ex. 1005). 2 Electronic On-Board Recorders for Hours-of-Service Compliance, 75 Fed. Reg. 17207, pub. April 5, 2010 (Ex. 1007). 3 U.S. Pat. No. 8,788,139 B2, iss. July 22, 2014 (Ex. 1008). IPR2021-00325 Patent 10,255,575 B2 3 petition, we review the decision for an abuse of discretion. 37 C.F.R. § 42.71(c). III. ANALYSIS A. The assertion that the Board made erroneous findings by overlooking and misapprehending arguments and evidence in the Petition regarding the disclosure of Nehowig In the Request, Petitioner argues as follows: The Board concluded “[a]lthough the Petition shows a skilled artisan knew that external diagnostic equipment designed to connect to the port of a vehicle’s internal onboard computer may be enabled to automatically adapt to a detected type of communication protocol the computer uses, it provides an insufficient basis to further determine that it would have been obvious to modify the vehicle’s onboard computer to have the same capability to communicate with a vehicle’s engine control module.” (ID, 20.) The Board premised its conclusion on two factual findings: 1) Nehowig’s onboard computer (“OBC”) is an internal vehicle computer; and 2) Nehowig’s diagnostic connections are “external” for coupling to a diagnostic computer. These factual findings are [] erroneous. . . . Nehowig’s OBC is adaptable for use in different vehicles. . . . Th[e] evidence, overlooked by the Board, established Nehowig’s OBC is a separate component, designed to operate with multiple types within a fleet using different connections/protocols. . . . The Petition . . . established Nehowig’s OBC uses the “‘vehicle diagnostics connections (e.g., J1708, J1909, CAN, OBDII, etc.)’ to connect to the ECM and engine data bus as shown in Figure 2. . . . (PS-1005, ¶22; PS-1006, 6:2-4.).” . . . The Petition demonstrated that Nehowig’s OBC has a connection to the ECM via the data bus to receive diagnostic data and is designed to interface with different types of vehicles and therefore different ECMs having different capabilities that IPR2021-00325 Patent 10,255,575 B2 4 communicate data using different types of diagnostic protocols/connections. . . . the Board overlooked and misapprehended the Petition’s argument and evidence showing that the OBC’s diagnostic connection is to the vehicle’s internal components (including the ECM), not separate diagnostic equipment. Req. Reh’g 2-6 (emphases added). We do not agree that we have overlooked or misapprehended evidence and arguments presented in the Petition, or that we have made erroneous factual findings because of the alleged misapprehensions. As an initial matter, we note Petitioner’s assertions-that the Board made a factual finding that “Nehowig’s onboard computer (‘OBC’) is an internal vehicle computer” and “[t]he Board’s motivation to combine conclusion is premised on its factual finding that Nehowig’s OBC is a ‘vehicle’s internal onboard computer’” (Req. Reh’g 2, 8 (emphases added) (citing Dec. 20-22))-are unsupported, because our Decision actually referenced the “vehicle’s onboard computer” and the “vehicle’s internal engine control module” of Nehowig. See Dec. 20-22. For example, our Decision states: Although the Petition shows a skilled artisan knew that external diagnostic equipment designed to connect to the port of a vehicle’s internal onboard computer may be enabled to automatically adapt to a detected type of communication protocol the computer uses, it provides an insufficient basis to further determine that it would have been obvious to modify the vehicle’s onboard computer to have the same capability to communicate with a vehicle’s engine control module. In particular, as Patent Owner asserts, the diagnostic communication port, such as an OBD II connection, of Nehowig’s onboard computer is a wholly separate and distinct connection than its data bus 206 connection to the engine control module that provides engine data 208. . . . These connections, moreover, serve different purposes--the OBD II connection IPR2021-00325 Patent 10,255,575 B2 5 allows an external device to connect to the vehicle’s onboard computer and the data bus 206 connection allows the vehicle’s onboard computer to communicate with the vehicle’s internal engine control module. . . . the Petition does not demonstrate that a similar problem [(to that described by Fedorchuk)] was known to exist with the connection between a vehicle’s onboard computer and its engine control module. . . . The Petition thus provides insufficient evidence to support a finding that it was known for onboard computers to automatically handle multiple protocols used by an engine control module or that a skilled artisan would have been motivated to modify the onboard computer in Nehowig in view of Fedorchuk to arrive at the claimed invention. Dec. 20-22, 24 (emphases added) (citing Ex. 1005 ¶¶ 20-26, Fig. 2; Ex. 1008, 1:23-46, 3:24-30, 4:12-15, 7:19-21). The Decision’s references to the “vehicle’s internal engine control module” and to the OBC as the “vehicle’s onboard computer,” are explicitly supported by Nehowig. See Ex. 1005 ¶¶ 2 (“Embodiments described in this disclosure are generally directed to a portable computing device removably connectable to a vehicle onboard computer.”), 23 (“vehicles such as commercial trucks typically include an engine control module (ECM) or other electronic control unit that is associated with the engine of the respective vehicle”), 26 (“OBC 204 is representative of what may reside in each vehicle monitored in accordance with embodiments of the disclosure. In one embodiment the OBC 204 is powered by the power system of the vehicle and includes a processor(s).”). We are also unpersuaded that our Decision “overlooked and misapprehended the Petition’s argument and evidence showing that the OBC’s diagnostic connection [(via the OBDII mentioned in Nehowig’s paragraph 22)] is to the vehicle’s internal components (including the ECM), IPR2021-00325 Patent 10,255,575 B2 6 not separate diagnostic equipment.” See Req. Reh’g 6; see also Req. Reh’g 4-5 (“The Petition also established Nehowig’s OBC uses the ‘vehicle diagnostics connections (e.g., J1708, J1909, CAN, OBDII, etc.)’ to connect to the ECM and engine data bus as shown in Figure 2. . . . The Board . . . overlooked and misapprehended the Petition’s evidence and arguments.”). Our Decision expressly addressed Petitioner’s arguments and evidence regarding Nehowig’s OBDII diagnostics connections, where the Decision noted: Although the Petition shows a skilled artisan knew that external diagnostic equipment designed to connect to the port of a vehicle’s internal onboard computer may be enabled to automatically adapt to a detected type of communication protocol the computer uses, it provides an insufficient basis to further determine that it would have been obvious to modify the vehicle’s onboard computer to have the same capability to communicate with a vehicle’s engine control module. . . . [A]s Patent Owner asserts, the diagnostic communication port, such as an OBD II connection, of Nehowig’s onboard computer is a wholly separate and distinct connection than its data bus 206 connection to the engine control module that provides engine data 208. . . . These connections, moreover, serve different purposes-the OBD II connection allows an external device to connect to the vehicle’s onboard computer and the data bus 206 connection allows the vehicle’s onboard computer to communicate with the vehicle’s internal engine control module. Ex. 1005 ¶¶ 20, 22, 23. Because these connections serve different functions, it logically follows that they may present different problems to solve, which we find the evidence supports here. Dec. 20-21. Nonetheless, we have reconsidered our determination in light of Petitioner’s arguments and the evidence reiterated in the Request for Rehearing, but are not persuaded these arguments and evidence alter our determination. IPR2021-00325 Patent 10,255,575 B2 7 Petitioner’s cited evidence for the assertion that “Nehowig’s OBC uses the ‘vehicle diagnostics connections (e.g., J1708, J1909, CAN, OBDII, etc.)’ to connect to the ECM and engine data bus as shown in Figure 2” (see Req. Reh’g 1, 4, 6, 8) includes paragraphs 22, 23, 42, and 45 of Nehowig (see Req. Reh’g 4-5, 7-8). We are not persuaded, however, that paragraphs 22, 23, 42, and 45 of Nehowig support Petitioner’s assertion because: (i) Nehowig’s paragraph 22 merely states that “OBC 204 connections may include, for example, universal serial bus (USB) connectors and vehicle diagnostics connections (e.g. J1708, J1909, CAN, OBDII, etc.),” but paragraph 22 does not specify that the “vehicle diagnostics connections” such as the OBDII would be used to connect to the vehicle’s ECM and its engine data bus (206 shown in Figure 2); (ii) Nehowig’s paragraph 23 describes the vehicle’s ECM module and its engine data bus that provides engine data (208) to the OBC, but does not specify that the “vehicle diagnostics connections” from paragraph 22 are used to provide the engine data 208; (iii) Nehowig’s paragraph 42 provides that “data flows [] from the OBC to the in-cab computing device, such as ECM data and the like,” but makes no mention of the vehicle diagnostics connections (i.e., OBDII from paragraph 22) being used to connect to the vehicle’s ECM and engine data bus; and (iv) Nehowig’s paragraph 45 provides that the “in-cab computing device may . . . be implemented as an in-cab, advanced tablet-based PC to enable mobile communications, messaging, forms processing, vehicle diagnostics,” but makes no mention of the OBC’s vehicle diagnostics connections (such as the OBDII from paragraph 22). See Ex. 1005 ¶¶ 22, 23, 42, 45 (emphasis added), Fig. 2. Thus, we maintain that the diagnostic communication port, such as an OBD II connection, of Nehowig’s onboard computer is a wholly separate IPR2021-00325 Patent 10,255,575 B2 8 and distinct connection than its data bus 206 connection to the engine control module that provides engine data 208. . . . These connections, moreover, serve different purposes-the OBD II connection allows an external device to connect to the vehicle’s onboard computer and the data bus 206 connection allows the vehicle’s onboard computer to communicate with the vehicle’s internal engine control module. Dec. 21 (citing Ex. 1005 ¶¶ 20, 22, 23, Fig. 2). Although Petitioner may not agree with our determination, this is not sufficient to demonstrate that we misapprehended the teachings of Nehowig. Petitioner’s argument that “Nehowig’s OBC uses the ‘vehicle diagnostics connections (e.g., J1708, J1909, CAN, OBDII, etc.)’ to connect to the ECM and engine data bus” (see Req. Reh’g 4, 6, 8) is not persuasive because it is not supported by Nehowig’s disclosure. We are further unpersuaded that our Decision “overlooked and misapprehended the Petition’s evidence and arguments” that allegedly demonstrated that Nehowig’s OBC has a connection to the ECM via the data bus to receive diagnostic data and is designed to interface with different types of vehicles and therefore different ECMs having different capabilities that communicate data using different types of diagnostic protocols/connections. Req. Reh’g 5 (emphasis added); see also Req. Reh’g 3 (referencing “evidence, overlooked by the Board, established Nehowig’s OBC is a separate component, designed to operate with multiple types within a fleet using different connections/protocols”). Our Decision expressly addressed Petitioner’s arguments and evidence regarding Nehowig’s onboard computer and its protocol, where the Decision noted: Although the Petition shows a skilled artisan knew that external diagnostic equipment designed to connect to the port of a vehicle’s internal onboard computer may be enabled to automatically adapt to a detected type of communication IPR2021-00325 Patent 10,255,575 B2 9 protocol the computer uses, it provides an insufficient basis to further determine that it would have been obvious to modify the vehicle’s onboard computer to have the same capability to communicate with a vehicle’s engine control module. . . . Unlike Fedorchuk’s suggestion that the diagnostic equipment in a repair shop benefits from being able to adapt to different communication protocols used by different vehicle manufacturers, there is insufficient evidence that a vehicle’s onboard computer would also benefit from being able to select between various languages that an engine control module may use to communicate engine data. For example, Petitioner has not offered persuasive evidence of any suggestion in the prior art that Nehowig’s onboard computer may be used with multiple different engine control modules that communicate data in different languages. Nor has Petitioner offered persuasive evidence of any suggestion in Nehowig that its engine control module uses more than one language. Contrarily, Nehowig suggests that the onboard computer and engine control module are vehicle specific without an indication that either needs to be adaptable for use in multiple different vehicles. Dec. 20, 22 (emphases added). Nonetheless, we have reconsidered our determination in light of Petitioner’s arguments and the evidence reiterated in the Request for Rehearing, but are not persuaded these arguments and evidence alter our determination. Petitioner cites paragraphs 18, 19, 21, 22, 61, and 71 of Nehowig for the assertion that “Nehowig’s OBC is . . . designed to operate with multiple types [of vehicles] within a fleet using different connections/protocols.” See Req. Reh’g 3-5 (emphases added). We are not persuaded, however, that the cited portions of Nehowig support Petitioner’s assertion because: (i) Nehowig’s paragraphs 18 and 19 broadly state that Nehowig’s implementations are applicable “to other vehicle types [in addition to trucks]” and “may be used in connection with vehicles ranging from a single IPR2021-00325 Patent 10,255,575 B2 10 vehicle to large fleets of vehicles having different characteristics” but paragraphs 18 and 19 do not mention the OBC (onboard computer), and do not specify that one OBC is adaptable for use in different vehicles; (ii) Nehowig’s paragraph 21 provides that onboard computing on fleet vehicles enables a mobile communication vendor to “obtain information such as GPS or other location data, electronic engine data, onboard event recording information and the like,” but paragraph 21 does not specify that one OBC is adaptable for use in different vehicles; (iii) Nehowig’s paragraph 22 (and Figure 2 referenced therein) describes “a representative vehicle system 200 utilizing an in-cab computing device 202” and “onboard computer (OBC) 204” which has ““OBC 204 connections [that] may include . . . vehicle diagnostics connections,” but paragraph 22 and Figure 2 do not disclose that OBC 204 is adaptable for use in different vehicles using different protocols; and (iv) Nehowig’s paragraph 61 and 71 describe applications and services provided by the in-cab computing device, but do not mention that an OBC might be adaptable for use in different vehicles with different ECMs. See Ex. 1005 ¶¶ 18, 19, 21, 22, 61, 71. In addition, the OBC being “mounted in a vehicle” (see Nehowig’s Abstract, referenced at Req. Reh’g 3) does not evidence an adaptability of the OBC to different vehicles or protocols. In view of the foregoing, we discern no reason to modify the Decision Denying Institution. B. The assertion that the Petition established motivations to combine Nehowig and Fedorchuk, and the Board overlooked those motivations In the Request, Petitioner argues the Board, in addition to overlooking the Petition’s arguments and evidence discussed supra, further overlooked motivations to combine set forth in the Petition. Req. Reh’g 8. More particularly, Petitioner argues the Petition’s “evidence of multiple IPR2021-00325 Patent 10,255,575 B2 11 connections/protocols for fleet management supports the motivation set forth in the Petition that a ‘POSITA would have been motivated to incorporate the components of Fedorchuk’s interface device supporting multiple protocols. . . . into Nehowig’s OBC.’” Req. Reh’g 8 (citing Pet. 21-22). Petitioner’s Rehearing Request references motivations that, had they not been allegedly overlooked by the Board, would have “establish[ed] that the combination of Nehowig and Fedorchuk discloses a ‘control circuitry configured to detect one or more protocols and to automatically adapt to the detected one or more protocols to communicate with an engine control module of the vehicle to gather vehicle usage data during operation of the vehicle.’” See Req. Reh’g 9-10. We are unpersuaded that our Decision overlooked Petitioner’s cited evidence and motivations. Our Decision expressly addressed Petitioner’s motivations to combine the teachings of Nehowig and Fedorchuk, where the Decision noted: Petitioner’s reliance on a motivation to identify techniques for automatically handling multiple protocols used by various vehicle manufacturers or on the same vehicle lacks support to explain why it would have been obvious to modify an onboard computer, such as the one Nehowig discloses, to include a multi- protocol vehicle diagnostic interface. At most, Petitioner’s contention, as supported by Dr. Wilhelm’s Declaration, is that a skilled artisan reading Nehowig and Fedorchuk would have understood that the combination would allow for programing an onboard computer to automatically handle multiple protocols used by an engine control module. But that reasoning seems to say no more than that a skilled artisan, once presented with the two references, would have understood that they could be combined. The Federal Circuit, however, has held “that is not enough: it does not imply a motivation to pick out those two references and combine them to arrive at the claimed invention.” IPR2021-00325 Patent 10,255,575 B2 12 Personal Web Techs., LLC v. Apple, Inc., 848 F.3d 987, 993-94 (Fed. Cir. 2017). Dec. 24. More particularly, with respect to the alleged “overlooked . . . motivations” (relying on evidence that “the use of multiple vehicle communication protocols in different vehicles was widely known” and that “it was common knowledge to a POSITA . . . that a single vehicle incorporates numerous diagnostic protocols,” see Req. Reh’g 8-9), our Decision expressly addressed those motivations. For example, the Decision noted: Petitioner has not offered persuasive evidence of any suggestion in the prior art that Nehowig’s onboard computer may be used with multiple different engine control modules that communicate data in different languages. Nor has Petitioner offered persuasive evidence of any suggestion in Nehowig that its engine control module uses more than one language. Contrarily, Nehowig suggests that the onboard computer and engine control module are vehicle specific without an indication that either needs to be adaptable for use in multiple different vehicles. . . . Additionally, regardless of whether Nehowig’s ECM uses one or multiple communication protocols, Petitioner does not provide persuasive evidence that it would have been obvious to modify Nehowig’s OBC 204 to meet limitation 1A.1. Fedorchuk discloses a device configured for connecting to and communicating with a diagnostic communication port of any of a variety of vehicles using any of a number of different possible protocols, enabled by interface device 10’s ability to detect the different possible protocols. . . . Petitioner does not provide persuasive evidence that Nehowig’s OBC 204 would be connected to any ECM without OBC 204 and the ECM already configured to communicate specifically with one another using one more predesignated protocols. . . . Petitioner does not provide persuasive evidence that Nehowig’s OBC 204 would not already have dedicated provisions for communicating with the ECM in the specific protocol(s) the ECM uses. Nehowig clearly discloses that OBC 204 already can communicate with Nehowig’s ECM, apparently using whatever protocol(s) the IPR2021-00325 Patent 10,255,575 B2 13 ECM uses. [Ex. 1005] ¶ 23. Accordingly, Petitioner has not shown sufficiently a reason that a person of ordinary skill in the art would have modified Nehowig’s OBC 204 to allow it to communicate with the ECM. Dec. 22-23 (emphases added). Nonetheless, we have reconsidered our determination in light of Petitioner’s arguments and the evidence reiterated in the Request for Rehearing, but are not persuaded these arguments and evidence alter our determination. In particular, a necessary factual underpinning to Petitioner’s obviousness contentions is that “Nehowig’s OBC has a connection to the ECM (and other internal vehicle components) to receive vehicle (diagnostic) data and supports various connection types and protocols” that include the “J1708, J1909, CAN, OBDII” referenced in Nehowig’s paragraph 22. See Req. Reh’g 8 (emphases added). Petitioner contends “[t]his evidence of multiple connections/protocols for fleet management supports the motivation set forth in the Petition.” See id. As discussed supra and in our Decision, we considered the disclosure of Nehowig and Petitioner’s cited evidence, and determined that Nehowig and the accompanying evidence did not support Petitioner’s contentions that Nehowig teaches or suggests (i) that its OBC connects to the ECM via the OBDII referenced in paragraph 22, or (ii) that Nehowig’s OBC may be used with multiple different engine control modules that communicate data in different languages/protocols. See Dec. 21-22. Rather, Nehowig describes an OBC whose “connections may include, for example, universal serial bus (USB) connectors and vehicle diagnostics connections (e.g. J1708, J1909, CAN, OBDII, etc.),” but Nehowig does not specify that the “vehicle diagnostics connections (e.g. J1708, J1909, CAN, OBDII, etc.)” are used to connect the OBC to the engine data bus or the ECM. See Ex. 1005 ¶¶ 22-23, Fig. 2. IPR2021-00325 Patent 10,255,575 B2 14 In view of the foregoing, we are not persuaded of any error in our Decision that Petitioner failed to demonstrate that it would have been obvious to modify Nehowig’s OBC to meet limitation 1A.1. See Dec. 23. C. The assertion that the Board made erroneous findings by overlooking arguments and evidence in the Petition regarding the DOT Regulations’ disclosure In the Request, Petitioner argues as follows: The Board overlooked the Petition’s evidence that the DOT Regulations mandate a wired connection and transfer. . . . the Board’s factual finding [that wired operation is optional in an EOBR [(Electronic On-Board Recorder)] implementing the DOT Regulations] was in error because it overlooked arguments and evidence presented in the Petition that the DOT Regulations mandate that an EOBR include a data connection port (USB Interface) and support wired transfer of reports to a remote computer in addition to wireless transfer. . . . The Petition established that the OBC (i.e. the “EOBR” in the DOT regulations) in the combined system must have the capability to export the driver report via a wired connection (USB port) to a remote computer to comply with the DOT Regulations. Specifically, the Petition established the DOT Regulations mandate a wired connection from the EOBR (Neohwig’s[sic] OBC) to a safety assurance officer’s computer to facilitate the transfer. . . . the Petition established that Nehowig’s OBC in the combined system must have the capability to transfer the driver report (comprising HOS [(hours-of-service)] information) to a remote computer of an officer (i.e. through wired connection). Req. Reh’g 11-12 (emphases added) (citing Ex. 1007, 17228 (§ 6.8.4), 17247 (49 C.F.R. § 395.16(i)(4)-(5)), 17230 (§ 6.8.6)); see also Req. Reh’g 1 (“the DOT Regulations mandate (not optional) an electronic IPR2021-00325 Patent 10,255,575 B2 15 onboard recorder (‘EOBR’) include a data connection port (USB) and be capable of a wired transfer”). We do not agree that we have overlooked evidence and arguments presented in the Petition, or that we have made erroneous factual findings because of the alleged oversight. Our Decision expressly addressed Petitioner’s arguments and evidence regarding the Regulations, where the Decision noted: Petitioner . . . asserts that “[t]he DOT Regulations state that the ‘[e]lectronic records must be capable of one-way transfer through wired and wireless methods to portable computers used by roadside safety assurance officials. . . .’” Id. at 43-44 (citing Ex. 1007, 17247). . . . Petitioner . . . implies that the DOT Regulations require the claim’s recited flow of the hours of service information from the wireless-capable portable terminal, where it is generated and saved, to the onboard unit so that the report may be transmitted via wired connection to the safety officer. We do not find Petitioner’s arguments to be persuasive. As for the part of the DOT Regulations indicating that the report must be transferred without requiring the safety officer to enter the vehicle, the wired operation is not the only option discussed in the DOT Regulations. Rather, the DOT Regulations also allow the transfer to occur via “a wireless transfer of the RODS [(Records of Duty Status)] data to the officer’s portable computer.” Ex. 1007, 17228 (Section 6.8.4)); see also id. at 17230 (“For a wired transfer [i.e. not every transfer], the roadside enforcement official will provide a cable to the driver. . . .” (emphasis added)). . . . The one-way transfer of the DOT Regulations is between the vehicle and the inspector (and may be wired or wireless). Dec. 26-27 (emphases added). Nonetheless, we have reconsidered our determination in light of Petitioner’s arguments and the evidence reiterated in the Request for Rehearing, but are not persuaded these arguments and evidence alter our determination. Petitioner’s cited evidence for the assertion that “the DOT IPR2021-00325 Patent 10,255,575 B2 16 Regulations mandate a wired connection from the EOBR . . . to a safety assurance officer’s computer to facilitate the transfer” (see Req. Reh’g 11 (emphasis added)) includes pages 17228 (§ 6.8.4), 17247 (49 C.F.R. § 395.16(i)(4)-(5)), and 17230 (§ 6.8.6) of the DOT Regulations (see Req. Reh’g 11-12). We are not persuaded, however, that the cited portions of the Regulations support Petitioner’s assertion because: (i) page 17228 (§ 6.8.4) of DOT Regulations instructs that an “enforcement official will provide a cable to the driver to plug into the EOBR, or request the driver initiate a wireless transfer of the RODS data to the officer’s portable computer” (emphasis added), which indicates that a wired connection is not the exclusive method of transfer required by the Regulations; (ii) page 17247 (49 C.F.R. § 395.16(i)(4)-(5)) of the Regulations provide that “Electronic records must be capable of one-way transfer through wired and wireless methods to portable computers used by roadside safety assurance officials” (emphasis added), again indicating that a wired connection is not the exclusive method of transfer required by the Regulations; and (iii) page 17230 (§ 6.8.6) of the Regulations provides that “The final rule requires the use of wired (direct physical connection) and wireless communications (WiFi and cellular, as described in more detail below) of the electronic RODS data record” (emphasis added), which, again, indicates that a wired connection is not the exclusive method of transfer required by the Regulations. See Ex. 1007, 17228 (§ 6.8.4), 17247 (49 C.F.R. § 395.16(i)(4)-(5)), 17230 (§ 6.8.6). Petitioner emphasizes that page 17230 (§ 6.8.6) of the DOT Regulations instructs that “[t]o ensure a reliable means of data exchange between each EOBR device and a roadside safety official’s portable computer,” each “EOBR device must implement a single USB compliant interface featuring a Type-B connector.” See Req. Reh’g 11-12 IPR2021-00325 Patent 10,255,575 B2 17 (citing Ex. 1007, 17230 (§ 6.8.6)). These instructions, however, pertain to the Regulations’ explanatory section providing a Response: The final rule requires the use of wired (direct physical connection) and wireless communications (WiFi and cellular, as described in more detail below) of the electronic RODS data record. For a wired transfer, the roadside enforcement official will provide a cable to the driver to be inserted into the EOBR’s USB data port. . . . To ensure a reliable means of data exchange between each EOBR device and a roadside safety official’s portable computer, the following hardware interface specifications are required: 1. Each EOBR device must implement a single USB compliant interface featuring a Type-B connector. See Ex. 1007, 17230 (§ 6.8.6) (emphases added). That is, the “USB compliant interface” referenced by Petitioner (see Req. Reh’g 11-12) pertains to the wired data transfer option encompassed by the Regulations’ final rule. See Ex. 1007, 17230. The USB detail does not, however, invalidate the existence of the other data transfer option encompassed by the Regulations’ rule-the wireless transfer option. See Ex. 1007, 17230 (referencing the use of “wireless communications (WiFi and cellular . . .) of the electronic RODS data record”). Thus, we maintain that “the wired operation is not the only option discussed in the DOT Regulations,” as “the DOT Regulations allow wireless submission of the report.” Dec. 26-27. We therefore also remain unpersuaded that we have overlooked arguments and evidence by which “the Petition established the DOT Regulations mandate a wired connection from the EOBR (Neohwig’s OBC) to a safety assurance officer’s computer to facilitate the transfer” (see Req. Reh’g 11-12). Petitioner’s referenced IPR2021-00325 Patent 10,255,575 B2 18 arguments are premised on the unsubstantiated proposition that data transfer via wired connection is the exclusive way the Regulations will allow. D. The assertion that the Board misapprehended Petitioner’s combination between Nehowig and DOT Regulations In the Request, Petitioner argues the Board, in addition to overlooking arguments and evidence in the Petition regarding DOT Regulations, further “misapprehended Petitioner’s combination [employing the DOT Regulations] and its arguments and evidence.” Req. Reh’g 12-15. Petitioner reiterates that overlooked evidence establishes that the “DOT regulations mandate that an EOBR support transfer of the driver report to the remote computer of an officer via a wired connection” and the “wired connection [for transfer of electronic records to portable computers used by roadside safety assurance officials] must be from the EOBR (i.e. Neowhig’s OBC),” and then argues [t]he Board . . . overlooked and misapprehended the Petition’s explanation as to how the combined system exports the driver reports (continuing hours of service information) from the in-cab computing device to the safety assurance officer’s computer via the OBC (i.e. the required “one-way transfer”). . . . Specifically, upon request of the safety officer for a transfer of the driver reports to her computer via a wired connection, the driver report (which is on the in-cab computer device) is transferred to the OBC via the wireless (Bluetooth) connection. . . . The OBC then exports the driver report to the remote computer via the data connection port via the cable provided by the roadside safety officer. . . . [T]he Petition[] . . . established that a POSITA would configure Nehowig’s system to implement the DOT Regulations and this configuration results Nehowig’s in-cab device 202 being configured to wirelessly transfer the driver summary electronic report to OBC 204 for the purpose of exporting (transferring) the IPR2021-00325 Patent 10,255,575 B2 19 report to the remote computer of a roadside safety officer via wired connection. Id. at 14-15 (emphases added). We understand Petitioner to argue that we overlooked or misapprehended that the Petition identified a particular proposed combination. We acknowledged Petitioner’s proposed combination. See Dec. 25-26 (“Petitioner then describes a scenario, argued ‘[t]o achieve this goal [of not having the official enter the vehicle],’ where the official ‘will provide a cable to the driver to plug into the EOBR’ . . . . Based on this, Petitioner concludes ‘[t]herefore, the combined system of Nehowig and Fedorchuk implementing the DOT regulations discloses transferring the hours of service information from the OBC to a safety assurance officer’s computer via a data cable.’”). And, even had we overlooked or misapprehended it, the outcome would not change. Again, the basis for the Decision is that Petitioner failed to explain adequately and persuasively why a person of ordinary skill in the art would arrange the data flow in this manner. Dec. 27. In view of the foregoing, we are not persuaded of any error in our Decision that the Petition did not demonstrate a reasonable likelihood of establishing obviousness of limitation 1B.1. See Dec. 27-28. IV. CONCLUSION For the foregoing reasons, Petitioner has not demonstrated that we abused our discretion in not instituting an inter partes review of the challenged claims of the ’575 patent. IPR2021-00325 Patent 10,255,575 B2 20 V. ORDER Accordingly, it is ORDERED that Petitioner’s Request for Rehearing is denied. PETITIONER: Lori A. Gordon Brent P. Ray KING & SPALDING LLP gordon-ptab@perkinscoie.com bray@kslaw.com PATENT OWNER: Gianni Curti Michael W. De Vries Akshay S. Deoras Adam R. Alper KIRKLAND & ELLIS LLP gianni.cutri@kirkland.com michael.devries@kirkland.com akshay.deoras@kirkland.com adam.alper@kirkland.com