`571.272.7822
`
`
`Paper No. 13
`
` Filed: January 27, 2017
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`HYUNDAI MOTOR COMPANY, HYUNDAI MOTOR AMERICA,
`HYUNDAI MOTOR MANUFACTURING ALABAMA, LLC,
`KIA MOTORS CORPORATION, KIA MOTORS AMERICA, INC., and
` KIA MOTORS MANUFACTURING GEORGIA, INC.,
`Petitioner,
`
`v.
`
`BLITZSAFE TEXAS, LLC,
`Patent Owner.
`____________
`
`Case IPR2016-01477
`Patent 7,489,786 B2
`____________
`
`
`
`Before JAMESON LEE, MIRIAM L. QUINN, and
`KERRY BEGLEY, Administrative Patent Judges.
`
`BEGLEY, Administrative Patent Judge.
`
`
`
`DECISION
`Denying Institution of Inter Partes Review
`35 U.S.C. § 314(a), 37 C.F.R. § 42.108
`
`
`
`Hyundai Motor Company, Hyundai Motor America, Hyundai Motor
`
`Manufacturing Alabama, LLC, Kia Motors Corporation, Kia Motors
`
`America, Inc., and Kia Motors Manufacturing Georgia, Inc. (collectively,
`
`
`
`
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`“Petitioner”) filed a Petition requesting inter partes review of claims 1, 5–8,
`
`10, 14, 23, 24, 57, 60–62, 64, and 65 (“challenged claims”) of U.S. Patent
`
`No. 7,489,786 B2 (Ex. 1001, “the ’786 patent”). Paper 1 (“Pet.”). Blitzsafe
`
`Texas, LLC (“Patent Owner”) filed a Preliminary Response to the Petition.
`
`Paper 11 (“Prelim. Resp.”).
`
`Pursuant to 35 U.S.C. § 314(a), an inter partes review may not be
`
`instituted unless “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.” Having considered the Petition and the Preliminary Response, we
`
`determine that the information presented does not show that there is a
`
`reasonable likelihood that Petitioner would prevail in establishing the
`
`unpatentability of any of the challenged claims of the ’786 patent.
`
`Accordingly, we deny institution of an inter partes review.
`
`I. BACKGROUND
`
`A. RELATED MATTERS
`
`
`
`The parties represent that the ’786 patent is the subject of five ongoing
`
`infringement actions before the U.S. District Court for the Eastern District of
`
`Texas and was previously the subject of two infringement actions before the
`
`U.S. District Court for the District of New Jersey. Paper 8, 1–2; Pet. 2. In
`
`addition, the ’786 patent is or was previously the subject of several inter
`
`partes review proceedings before the Office, namely IPR2016-00421,
`
`IPR2016-00422, IPR2016-01448, and IPR2016-01472. Paper 8, 2; see
`
`Pet. 2. Related U.S. Patent No. 8,155,342 B2 is or was previously involved
`
`in IPR2016-00118, IPR2016-00418, IPR2016-00419, IPR2016-01445,
`
`IPR2016-01449, IPR2016-01473, IPR2016-01476, IPR2016-01533,
`
`IPR2016-01557, and IPR2016-01560. See Paper 8, 2.
`
`
`
`2
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`B. THE ’786 PATENT
`
`The ’786 patent explains that integrating an after-market audio system
`
`with an existing car stereo, such as a stereo from an original equipment
`
`manufacturer (“OEM”), presents a problem because signals generated by
`
`both systems are in a “proprietary format” and “are not capable of being
`
`processed” or recognized by the other system. Ex. 1001, 1:3642; see id. at
`
`2:26–29. Thus, “in order to integrate after-market systems with car stereos,
`
`it is necessary to convert signals between such systems.” Id. at 1:4244.
`
`The ’786 patent is directed to an audio device integration system that
`
`allows after-market audio devices to be integrated for use with an existing
`
`car stereo system, such that control commands can be issued at the car stereo
`
`for execution by the audio device and data from the audio device can be
`
`displayed on the car stereo. Id. at [57], 2:12–42. More specifically, control
`
`commands generated at the car stereo are received, converted into a format
`
`recognizable by the after-market audio device, and dispatched to the device
`
`for execution. Id. at [57], 2:35–40. In addition, information from the audio
`
`device, such as track, channel, song, and artist information, is received,
`
`processed, converted into a format recognizable by the car stereo, and
`
`dispatched to the stereo for display. Id. at [57], 2:40–47. The audio device
`
`could, for example, comprise a “CD player, CD changer, MP3 player,
`
`satellite receiver, [or] digital audio broadcast (DAB) receiver.” Id. at 4:28–
`
`30; see id. at [57], 2:23–26. Figures 2A–2C are reproduced below:
`
`
`
`3
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`
`
`
`Figures 2A–C illustrate embodiments in which a car stereo is integrated with
`
`a CD player (Figure 2A), an MP3 player (Figure 2B), and a satellite radio or
`
`DAB receiver (Figure 2C). Id. at 3:14–23.
`
`In addition, an audio device as well as auxiliary input sources may be
`
`integrated with a car stereo. Id. at [57], 2:53–56. A user then “can select
`
`between the external audio device and the auxiliary input using the controls
`
`of the car stereo.” Id. at 2:56–57. Figure 1 is reproduced below:
`
`
`Figure 1 illustrates an embodiment integrating a car stereo with a CD player,
`
`a MP3 player, and a satellite radio or DAB receiver, as well as a number of
`
`auxiliary input sources. Id. at 3:12–13, 5:14–27.
`
`As shown in the above figures, central to the ’786 patent is an
`
`“interface” positioned between the car stereo and the audio device(s) and
`
`auxiliary input(s). See, e.g., id. at Fig. 1, 2A–C, 5:33–36. The interface
`
`
`
`4
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`allows for the integration of the audio devices and auxiliary inputs with the
`
`OEM or after-market car stereo. Id. at 5:33–36.
`
`C. ILLUSTRATIVE CLAIM
`
`Of the challenged claims, claims 1 and 57 of the ’786 patent are
`
`independent. Claim 1, reproduced below, is illustrative:
`
`1. An audio device integration system comprising:
`a first connector electrically connectable to a car stereo;
`a second connector electrically connectable to an after-market
`audio device external to the car stereo;
`a third connector electrically connectable to one or more
`auxiliary input sources external to the car stereo and the
`after-market audio device;
`an interface connected between said first and second electrical
`connectors for channeling audio signals to the car stereo
`from the after-market audio device, said interface including
`a microcontroller in electrical communication with said first
`and second electrical connectors, said microcontroller
`pre-programmed to execute:
`a first pre-programmed code portion for remotely controlling
`the after-market audio device using the car stereo by
`receiving a control command from the car stereo through
`said first connector in a format incompatible with the
`after-market audio device, processing
`the received
`control command into a formatted command compatible
`with the after-market audio device, and transmitting the
`formatted command to the after-market audio device
`through said second connector for execution by the
`after-market audio device;
`a second pre-programmed code portion for receiving data
`from the after-market audio device through said second
`connector in a format incompatible with the car stereo,
`processing
`the
`received data
`into
`formatted data
`compatible with the car stereo, and transmitting the
`formatted data to the car stereo through said first
`connector for display by the car stereo; and
`
`
`
`5
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`a third pre-programmed code portion for switching to one or
`more auxiliary input sources connected to said third
`electrical connector.
`
`Ex. 1001, 21:31–64.
`
`D. ASSERTED PRIOR ART
`
`The Petition relies upon the following asserted prior art references:
`
`U.S. Patent No. 5,794,164 (issued Aug. 11, 1998) (Ex. 1007,
`“Beckert ’164”);
`
`U.S. Patent No. 6,009,363 (issued Dec. 28, 1999) (Ex. 1008,
`“Beckert ’363”);
`
`U.S. Patent No. 7,085,710 B1 (filed Jan. 7, 1998) (issued Aug. 1, 2006)
`(Ex. 1006, “Beckert ’710”);
`
`Clarion AutoPC 310C Owner’s Manual (1998) (Ex. 1009, “AutoPC
`Manual”);
`
`Universal Serial Bus Device Class Definition for Audio Data Formats
`(Release 1.0 1998) (Ex. 1011, “USB ADF”);
`
`Sony Corporation, FM/MW/LW Cassette Car Stereo (1999) (Ex. 1012,
`“Sony XR-C5120R Manual”); and
`
`Universal Serial Bus Specification (Rev. 2.0 2000) (Ex. 1010, “USB 2.0”).
`
`In addition to these references, the Petition supports its contentions with the
`
`Declaration of Chris Kyriakakis, Ph.D. (Ex. 1003).
`
`E. ASSERTED GROUNDS OF UNPATENTABILITY
`
`Petitioner asserts the following grounds of unpatentability. Pet. 8–9.
`
`Challenged
`Claim(s)
`1, 10, 14,
`23, and 24
`
`Basis
`
`References
`
`§ 1031 Beckert ’710 and Beckert ’164
`
`
`1 The Leahy-Smith America Invents Act (“AIA”), Pub. L. No. 112–29, 125
`Stat. 284, 287–88 (2011), revised 35 U.S.C. § 103, effective March 16,
`2013. Because the patent application resulting in the ’786 patent was filed
`before the effective date of the AIA, we refer to the pre-AIA version of
`§ 103 throughout this Decision.
`
`
`
`6
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`5
`
`6
`
`7
`
`8
`
`57, 60, 64,
`and 65
`61
`
`62
`
`
`
`§ 103 Beckert ’710, Beckert ’164, AutoPC
`Manual, and USB 2.0
`§ 103 Beckert ’710, Beckert ’164,
`and Beckert ’363
`§ 103 Beckert ’710, Beckert ’164, and AutoPC
`Manual
`§ 103 Beckert ’710, Beckert ’164, and Sony
`XR-C5120R Manual
`§ 103 Beckert ’710, Beckert ’164, and USB ADF
`
`§ 103 Beckert ’710, Beckert ’164, USB ADF, and
`AutoPC Manual
`§ 103 Beckert ’710, Beckert ’164, USB ADF, and
`Sony XR-C5120R Manual
`
`II. ANALYSIS
`
`A. LEVEL OF ORDINARY SKILL IN THE ART
`
`We begin our analysis by addressing the level of ordinary skill in the
`
`art. We determine that in this case, no express articulation of the level of
`
`ordinary skill is necessary and that the level of ordinary skill in the art is
`
`reflected by the prior art of record. See Okajima v. Bourdeau, 261 F.3d
`
`1350, 1355 (Fed. Cir. 2001); In re GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir.
`
`1995); In re Oelrich, 579 F.2d 86, 91 (CCPA 1978).
`
`B. CLAIM CONSTRUCTION
`
`The Board interprets claims terms of an unexpired patent using the
`
`“broadest reasonable construction in light of the specification of the patent.”
`
`37 C.F.R. § 42.100(b); Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct. 2131,
`
`2144–46 (2016). Under this standard, we presume a claim term carries its
`
`“ordinary and customary meaning,” which “is the meaning that the term
`
`would have to a person of ordinary skill in the art” at the time of the
`
`invention. In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir.
`
`2007). A claim term will be interpreted more narrowly than its ordinary and
`
`
`
`7
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`customary meaning only where: (1) the “patentee sets out a definition and
`
`acts as [its] own lexicographer,” or (2) the “patentee disavows the full scope
`
`of a claim term either in the specification or during prosecution.” Aventis
`
`Pharma S.A. v. Hospira, Inc., 675 F.3d 1324, 1330 (Fed. Cir. 2012).
`
`1. “device presence signal”
`
`
`
`Independent claim 57 and dependent claim 6 each recite a “device
`
`presence signal.” Ex. 1001, 22:13–15, 26:23–27. Specifically, claim 57
`
`requires that a microcontroller within an interface be pre-programmed to
`
`execute “a first pre-programmed code portion for generating a device
`
`presence signal and transmitting the signal to the car stereo to maintain the
`
`car stereo in an operational state.” Id. at 26:17–27 (emphasis added).
`
`Similarly, claim 6, which depends directly from independent claim 1,
`
`requires that the “interface generates a device presence signal for
`
`maintaining the car stereo in a state responsive to processed data and audio
`
`signals.” Id. at 22:13–15 (emphasis added).
`
`
`
`Petitioner states that in a prior Institution Decision in IPR2016-00421,
`
`the Board construed the term “device presence signal” as: “a signal
`
`indicating that an audio device (claim 57) or video device (claim 86) or
`
`portable audio device (claim 92), other than the car stereo, is connected to
`
`the interface.” Pet. 17–18 (quoting Toyota Motor Corp. v. Blitzsafe Texas,
`
`LLC, Case IPR2016-00421, slip op. at 18 (PTAB July 7, 2016) (Paper 13)
`
`(“IPR2016-00421 Inst. Dec.”)) (emphasis omitted). Petitioner represents
`
`that it adopts and applies this construction in the Petition. Id. at 18. Patent
`
`Owner also adopts this construction of the term. Prelim. Resp. 3.
`
`
`
`Having reconsidered the issue, we maintain our construction of the
`
`term “device presence signal” from the Institution Decision in
`
`
`
`8
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`IPR2016-00421 for the reasons given in that decision. IPR2016-00421 Inst.
`
`Dec. 16–18. We repeat the relevant analysis below.
`
`A description of a “device presence signal” is contained in the
`
`specification of the ’786 patent in the discussion of an embodiment that is
`
`for connecting a CD player to the car stereo:
`
`Beginning in step 110, a signal is generated by the present
`invention indicating that a CD player/changer is present, and
`the signal is continuously transmitted to the car stereo.
`Importantly, this signal prevents the car stereo from shutting
`off, entering a sleep mode, or otherwise being unresponsive to
`signals and/or data from an external source.
`
`Ex. 1001, 12:29–35 (emphasis added). All other disclosed embodiments,
`
`whether they are for connecting an MP3 player or an auxiliary device to the
`
`car stereo, refer back to this description of the device presence signal. Id.
`
`at 13:15–18, 13:62–65, 14:48–51, 15:35–38, 16:12–15, 16:57–60.
`
`As we explained in IPR2016-00421, continuous transmission of a
`
`signal is not necessary to accord meaning to “device presence signal.”
`
`IPR2016-00421 Inst. Dec. 17. The manner of transmission simply reflects
`
`how the signal is transmitted and does not change what the signal was
`
`generated and intended to accomplish, and actually accomplishes. Id. The
`
`specification also does not put continuous transmission in the same category
`
`of importance as the requirements in the italicized portion of the
`
`above-quoted text. Id.
`
`Moreover, in claims 6 and 57, the device presence signal is generated
`
`and transmitted by the interface that is connected between the first and
`
`second electrical connector, where the first electrical connector is
`
`connectable to a car stereo and the second electrical connector is connectable
`
`to an after-market audio device (claim 6) or portable MP3 player (claim 57).
`
`
`
`9
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`See Ex. 1001, 21:30–44, 22:13–15, 26:13–27; IPR2016-00421 Inst.
`
`Dec. 17–18. Claim 6, based on its dependency from claim 1, recites that the
`
`interface is for “channeling audio signals to the car stereo from the
`
`after-market audio device.” Ex. 1001, 21:38–44. Claim 57 recites that the
`
`interface is for “transmitting audio from a portable MP3 player to a car
`
`stereo.” Id. at 26:17–22. In the context of these claims, the device the
`
`presence of which is signaled by the interface is the device that connects to
`
`the interface to communicate with the car stereo.
`
`Accordingly, for purposes of this Decision, we adopt our previous
`
`construction of “device presence signal” from IPR2016-00421 and adjust
`
`this construction to reflect the relevant challenged claims in this proceeding:
`
`a signal indicating that an audio device (claim 6) or portable MP3 player
`
`(claim 57), other than the car stereo, is connected to the interface.
`
`2. Other Claim Terms
`
`
`
`Based on our review of the record and the dispositive issues in our
`
`determination of whether to institute inter partes review on the asserted
`
`grounds of unpatentability, we need not address the construction of any
`
`other claim terms. See Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d
`
`795, 803 (Fed. Cir. 1999) (holding that only claim terms that “are in
`
`controversy” need to be construed and “only to the extent necessary to
`
`resolve the controversy”); Pet. 14–18; Prelim. Resp. 3–5.
`
`C. ALLEGED OBVIOUSNESS OVER BECKERT ’710 AND BECKERT ’164
`
`Petitioner argues claims 1, 10, 14, 23, and 24 of the ’786 patent are
`
`unpatentable as obvious over Beckert ’710 and Beckert ’164. Pet. 8, 18–45.
`
`1. Beckert ’710
`
`
`
`Beckert ’710 discloses a vehicle computer system, implementing an
`
`audio entertainment system, that is designed to support multiple audio
`
`
`
`10
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`sources, such as radio, CD, and auxiliary inputs. Ex. 1006, [57], 1:5–9,
`
`1:60–63, 12:57–61. The disclosed vehicle computer system 20 includes
`
`three modules: (1) faceplate module 80, (2) support module 82, and
`
`(3) computer module 84. Id. at 1:63–65, 5:34–37, Fig. 3. Beckert ’710
`
`explains that support module 82 and computer module 84 typically reside in
`
`a stationary base unit that is mounted in the dashboard of a vehicle, whereas
`
`faceplate module 80 resides on a faceplate to the base unit. Id. at 5:55–58,
`
`6:48–49, 6:62–63, Fig. 1. Figure 3 is reproduced below.
`
`
`Figure 3 depicts one implementation of the vehicle computer system
`
`disclosed in Beckert ’710. Id. at 3:34–36.
`
`Beckert ’710 explains that support module 82 includes logic unit 110,
`
`which “performs many of the functions for the audio entertainment system.”
`
`Id. at 1:65–67, 5:55–58, 7:49–54. Logic unit 110 can be implemented as a
`
`“field programmable gate array (FPGA), application specific integrated
`
`circuit (ASIC), customized processor, or the like.” Id. at 1:67–2:3; see id.
`
`at 5:64–6:4. Support module 82 also features hardware interfaces, including
`
`universal serial bus (“USB”) interface 112, which connects support
`
`
`
`11
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`module 82 to various USB peripheral devices, such as a CD-ROM changer
`
`and a TV tuner. Id. at 5:44–54, 6:5–11.
`
`
`
`Beckert ’710 discloses that computer module 84 features
`
`microprocessor 150, which runs an operating system. Id. at 2:6–9, 6:62–65.
`
`According to Beckert ’710, “computer module 84 is operatively connected
`
`to the support module 82 via a multi-bit bus 86,” which is preferably a
`
`peripheral component interconnect (“PCI”) bus. Id. at 5:37–40; see id.
`
`at 2:9–11. In addition, faceplate module 88 is attached to support module 82
`
`through a “detachable connector.” Id. at 6:48–53.
`
`
`
`Beckert ’710 explains that “[a] more detailed explanation of the three
`
`modules in the vehicle computer system is provided in” the patent
`
`application that resulted in Beckert ’164 and “[a] detailed description of one
`
`implementation of the logic unit 110 is provided in” the patent application
`
`that resulted in Beckert ’363. Id. at 7:19–25, 7:37–47; Ex. 1007, [21];
`
`Ex. 1008, [21]. Beckert ’710 “incorporate[s]” these applications “by
`
`reference.” Ex. 1006, 7:19–25, 7:37–47.
`
`In addition, Beckert ’710 discloses that “computer system 20
`
`implements an audio manager API (application program interface) to enable
`
`applications running on the computer to control the various audio sources
`
`without knowing the hardware and implementation details of the underlying
`
`sound system.” Id. at 12:65–13:2; see id. at [54], 2:64–3:1. Figure 8 of
`
`Beckert ’710 is reproduced below.
`
`
`
`12
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`
`Figure 8 illustrates the “application-to-hardware architecture” discussed in
`
`Beckert ’710. Id. at 13:7; see id. at 3:44–45. Audio hardware 270 forms the
`
`lowest level of the architecture. Id. at 13:8–9. Audio hardware abstraction
`
`layer (“HAL”) 272, in turn, “defines a basic interface layer between the
`
`audio related drivers for the hardware 270 and the audio manager API
`
`layer 274.” Id. at 13:9–12. Next, audio manager API 274—which has five
`
`core components, audio source control API 278, wave-in and wave-out
`
`API 280, surround sound decoder API 282, equalization API 284, and
`
`volume/balance/fade API 286—“defines the APIs to access and control the
`
`underlying audio system.” Id. at 13:14–18. “[A]udio manager API 274
`
`communicates with the audio device drivers for specific devices via the
`
`audio HAL interface 272” and “transfers calls made by the applications to
`
`the appropriate device driver(s).” Id. at [57], 3:4–6, 13:5–6, 14:38–40.
`
`Finally, “[a]top the audio manager API 274 are the applications 276.” Id.
`
`at 13:13–14.
`
`
`
`Beckert ’710 further explains that “[d]ifferent APIs control different
`
`aspects of the audio system.” Id. at 13:19–20. For example, wave-out
`
`
`
`13
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`API 280 controls foreground audio sources, whereas audio source control
`
`API 278 “control[s]” and “is used to select” background audio sources,
`
`including the “AM/FM tuner, CD player, auxiliary inputs, and other sources
`
`from the USB.” Id. at 13:22–32, 13:39–47.
`
`2. Beckert ’164
`
`
`
`Similar to Beckert ’710, Beckert ’164 discloses a vehicle computer
`
`system with three modules, namely a computer module, support module, and
`
`faceplate module. Ex. 1007, [57], 1:4–5, 1:65, 2:22–42. Computer
`
`module 64 includes a processor that runs the operating system “to support
`
`the vehicle-related applications,” including “navigation, security,
`
`diagnostics, communications, and entertainment systems.” Id. at [57], 2:21–
`
`30, 3:14–17, 8:34–39.
`
`3. Discussion
`
`A patent claim is unpatentable as obvious under 35 U.S.C. § 103(a) 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.” 35 U.S.C. § 103(a). As the Supreme Court
`
`explained in KSR International Co. v. Teleflex Inc., 550 U.S. 398 (2007), an
`
`invention “composed of several elements is not proved obvious merely by
`
`demonstrating that each of its elements was, independently, known in the
`
`prior art.” Id. at 418. Rather, “it can be important to identify a reason that
`
`would have prompted a person of ordinary skill in the relevant field to
`
`combine the elements in the way the claimed new invention does.” Id. In
`
`other words, “there must be some articulated reasoning with some rational
`
`underpinning to support the legal conclusion of obviousness.” Id. (quoting
`
`In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006)). Accordingly, the U.S.
`
`
`
`14
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`Court of Appeals for the Federal Circuit has made clear that a petitioner in
`
`an inter partes review proceeding cannot “satisfy its burden of proving
`
`obviousness” by “employ[ing] mere conclusory statements” and “must
`
`instead articulate specific reasoning, based on evidence of record” to support
`
`an obviousness determination. In re Magnum Oil Tools Int’l, Ltd., 829 F.3d
`
`1364, 1380–81 (Fed. Cir. 2016).
`
`a. Independent Claim 1
`
`Independent claim 1 of the ’786 patent recites that the
`
`“microcontroller,” included in the “interface,” is “pre-programmed to
`
`execute: a first pre-programmed code portion for:”
`
`remotely controlling the after-market audio device using the car
`stereo by receiving a control command from the car stereo
`through said first connector in a format incompatible with
`the after-market audio device,
`processing the received control command into a formatted
`command compatible with the after-market audio device,
`and
`transmitting the formatted command to the after-market audio
`device through said second connector for execution by the
`after-market audio device.
`
`Ex. 1001, 21:38–54 (line breaks added). Accordingly, the claim requires
`
`that the recited microcontroller perform a format conversion of a control
`
`command received from the car stereo, specifically converting the command
`
`from a format incompatible with the after-market audio device to one
`
`compatible with the after-market audio device.
`
`
`
`Relevant to this claim requirement, Petitioner identifies support
`
`module 82 of Beckert ’710 as the recited “interface,” a customized processor
`
`implementing logic unit 110 of Beckert ’710 as the recited
`
`“microcontroller,” and computer module 84 of Beckert ’710 and
`
`corresponding computer module 64 of Beckert ’164 as the recited “car
`
`
`
`15
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`stereo.” See Pet. 22–24, 29–31. Specifically regarding the recited “first
`
`pre-programmed code portion for . . . processing the received control
`
`command into a formatted command compatible with the after-market audio
`
`device,” the Petition argues, and Dr. Kyriakakis opines, that audio manager
`
`API 274 and hardware abstraction layer 272 of Beckert ’710 perform the
`
`required format conversion. Id. at 32–35; Ex. 1003, 40–43; see Pet. 31–32;
`
`Ex. 1003, 39–40. The Petition and Dr. Kyriakakis’s declaration represent
`
`that in Beckert ’710, “commands issued by the car stereo (e.g., from the
`
`Computer Applications 276) . . . are converted through the Audio Manager
`
`API and the hardware abstraction layer to be able to communicate with a
`
`connected USB audio hardware device.” Pet. 35; Ex. 1003, 43. According
`
`to Petitioner, Beckert ’710 describes using the hardware abstraction layer “to
`
`process received commands from the car stereo into formatted commands
`
`for transfer to the audio system hardware.” Pet. 33; Ex. 1003, 41. Petitioner
`
`relies exclusively on these alleged teachings of Beckert ’710 and does not
`
`refer to Beckert ’164 for the “first pre-programmed code portion” limitation.
`
`See Pet. 31–35; Ex. 1003, 39–43.
`
`
`
`Patent Owner contests Petitioner’s arguments that Beckert ’710
`
`teaches the “first pre-programmed code portion” limitation, asserting that
`
`Petitioner merely “make[s] general allegations regarding an ‘API,’” but the
`
`API of Beckert ’710 “does not receive commands in an incompatible format,
`
`or translate commands.” Prelim. Resp. 12–13. Patent Owner argues that
`
`Beckert ’710 instead refers to “several other components involved in the
`
`command structure including device ‘drivers’ as well as the hardware itself.”
`
`Id. at 13. According to Patent Owner, Beckert ’710 expressly states only
`
`that the API “‘transfers calls made by the applications to the appropriate
`
`device drivers’” and does not “describe the format that commands are
`
`
`
`16
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`relayed from an API to a device driver and then subsequently to the
`
`devices.” Id. (quoting Ex. 1006, 2:64–3:6). Moreover, Patent Owner faults
`
`Petitioner for failing to “allege the location of the API with any further
`
`specificity” than Beckert ’710 itself, which states merely that the API is
`
`within the “vehicle computer system.” Id. Therefore, according to Patent
`
`Owner, Petitioner’s allegations are insufficient to demonstrate that
`
`Beckert ’710’s teaches the claim limitation because the vehicle computer
`
`system contains not only the component Petitioner identifies as the alleged
`
`“interface” but also the components Petitioner identifies as the alleged “car
`
`stereo” and “after-market audio device.” Id. Moreover, with regard to the
`
`hardware abstraction layer, Patent Owner asserts that Petitioner does “not
`
`map the hardware abstraction layer to the conversion limitations” and does
`
`“not explain where the . . . [l]ayer is located or how it represents
`
`‘pre-programmed’ code.” Id.
`
`
`
`We agree with Patent Owner that Petitioner has not sufficiently
`
`explained and supported its position that Beckert ’710 teaches or suggests
`
`claim 1’s requirement that a microcontroller “process[] the received control
`
`command into a formatted command compatible the after-market audio
`
`device.” See id. Nor has Petitioner adequately supported and explained its
`
`supporting assertion that this recitation is performed by audio manager
`
`API 274 and hardware abstraction layer 272, as opposed to, for example, the
`
`device drivers for specific audio devices. Moreover, even if this
`
`functionality is covered by audio manager API 274 and hardware abstraction
`
`layer 272, it is not explained adequately why or how either one maps to a
`
`“microcontroller” performing those functions.
`
`With regard to hardware abstraction layer 272, Petitioner’s citation to
`
`Figure 8 and the accompanying general disclosure that “audio hardware
`
`
`
`17
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`abstraction layer . . . 272 defines a basic interface layer between the audio
`
`related drivers for the hardware 270 and the audio manager API layer 274”
`
`fails to specify and show adequately that the hardware abstraction layer,
`
`rather than the device drivers of the audio devices, perform the format
`
`conversion of control commands required by claim 1. Ex. 1006, 13:9–12,
`
`Fig. 8; see Pet. 33–34 (citing Ex. 1006, 13:7–15, Fig. 8); Ex. 1003, 41–42
`
`(citing Ex. 1006, 13:7–15, Fig. 8).
`
`The relevant citations to Beckert ’710 regarding audio manager
`
`API 274 fare no better. Although Petitioner proffers citations to disclosures
`
`of Beckert ’710 that audio manager API 274 “enable[s] applications running
`
`on the computer to control the various audio sources without knowing the
`
`hardware and implementation details of the underlying sound system” and
`
`similarly, “defines the APIs to access and control the underlying audio
`
`system,” these general statements regarding “control” of audio sources do
`
`not show that audio manager API 274, in particular, converts a command
`
`into a format compatible with the relevant audio source device. Ex. 1006,
`
`[57], 2:64–3:1, 12:65–13:2, 13:14–15; see Pet. 32–34 (citing Ex. 1006,
`
`2:64–3:6, 13:7–15); Ex. 1003, 40–42 (citing Ex. 1006, 2:64–3:6, 13:7–15).
`
`Moreover, the cited discussion in Beckert ’710 explaining that audio source
`
`control 278, a component of audio manager API 274, “control[s]” and “is
`
`used to select” background audio sources, such as “sources from the USB,”
`
`similarly lacks detail sufficient to demonstrate that audio manager API 274
`
`performs the recited format conversion. Ex. 1006, 13:16–18, 13:28–31,
`
`13:39–41, Fig. 9; see Pet. 32, 34–35 (citing Ex. 1006, 13:22–31, 13:37–42,
`
`Fig. 9); Ex. 1003, 40, 42–43 (citing Ex. 1006, 13:22–31, 13:37–42, Fig. 9).
`
`
`
`In more particularly addressing the function of audio manager
`
`API 274, Beckert ’710 explains that its role is to “communicate[] with the
`
`
`
`18
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`audio device drivers for specific devices via the audio HAL interface 272”
`
`and “transfer[] calls made by the applications to the appropriate device
`
`driver(s).” Ex. 1006, [57], 3:2–6, 13:2–6, 14:37–40 (emphases added); see
`
`Pet. 32–34 (citing Ex. 1006, 2:64–3:6); Ex. 1003, 40–42 (citing Ex. 1006,
`
`2:64–3:6). Petitioner has not explained or demonstrated sufficiently, with
`
`adequate record support, that a person of ordinary skill in the art would have
`
`understood the function of audio manager API 274, including transferring
`
`calls to device drivers for audio devices through the hardware abstraction
`
`layer, to involve the recited format conversion of control commands.
`
`Petitioner also fails to address or provide explanation as to why it is
`
`not the device driver(s) for each specific audio device that perform such a
`
`conversion of a control command into a format compatible with the
`
`particular device. We find Petitioner’s failure in this regard particularly
`
`problematic given that device drivers were known in the art at the relevant
`
`time period to perform functionality consistent with the required format
`
`conversion. See Ex. 3001 (MICROSOFT COMPUTER DICTIONARY (5th ed.
`
`2002)), 155 (explaining that a “device driver” is “[a] software component
`
`that permits a computer system to communicate with a device” and performs
`
`“data translation”); Ex. 1001, [22]. Moreover, it is unclear why the
`
`individual device drivers for particular audio devices in Beckert ’710 would
`
`be necessary, and what function they would perform, if audio manager
`
`API 274 or hardware abstraction layer 272 converts control commands into a
`
`format compatible with the relevant audio device before the drivers receive
`
`the command.
`
`
`
`In addition, Petitioner has not addressed or shown that the device
`
`drivers in Beckert ’710 are part of the customized processor implementing
`
`logic unit 110 in support module 82, which Petitioner identifies as the
`
`
`
`19
`
`
`
`IPR2016-01477
`Patent 7,489,786 B2
`
`“microcontroller” of the “interface” recited in claim 1. See Pet. 29–35;
`
`Ex. 1003, 37–43; see also, e.g., Ex. 1006, [57], 3:2–3, 13:2–3 (“Different
`
`audio d