`Trials@uspto.gov
`Entered: December 6, 2018
`571-272-7822
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`DAIMLER AG,
`Petitioner,
`
`v.
`
`BLITZSAFE TEXAS, LLC,
`Patent Owner.
`____________
`
`Case IPR2018-01209
`Patent 8,155,342 B2
`____________
`
`
`
`Before JAMES T. MOORE, THOMAS L. GIANNETTI, and
`MIRIAM L. QUINN, Administrative Patent Judges.
`
`QUINN, Administrative Patent Judge.
`
`
`
`DECISION
`Denying Institution of Inter Partes Review and Denying Motion for Joinder
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`
`INTRODUCTION
`I.
`Petitioner, Daimler AG, filed a Petition requesting an inter partes
`review of claims 49–57, 62–64, 66, 68, 70, 71, 73–80, 83, 86−88, 94, 95, 97,
`99–103, 106, 109–111, 113, 115, and 120 (“the challenged claims”) of
`U.S. Patent No. 8,155,342 B2 (Ex. 1001, “the ’342 patent”). Paper 2
`(“Pet.”). Concurrent with the filing of its Petition, Petitioner filed a Motion
`for Joinder under 35 U.S.C. § 315(c), seeking to join IPR2018-00544.
`Paper 3 (“Mot.”).
`Patent Owner filed a Preliminary Response and an Opposition to
`Petitioner’s Motion for Joinder. Paper 9 (“Prelim. Resp.”); Paper 7
`(“Opp’n”). Petitioner filed a Reply to Patent Owner’s Opposition to the
`Motion for Joinder. Paper 8 (“Reply”).
`Under 35 U.S.C. § 315(c), at the discretion of the Director, a party
`may be joined to an instituted inter partes review. Under 35 U.S.C. § 314,
`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.” Because we did not institute inter partes
`review in IPR2018-00544, there is no inter partes review to which we could
`join Petitioner, and, therefore, we deny the Motion for Joinder. And further,
`for the same reasons we denied institution in IPR2018-00544, we do not
`institute inter partes review here.
`
`2
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`
`Related Matters
`A.
`Petitioner asserts that the’342 patent is the subject matter of district
`court ligitation pending in the Eastern District of Texas, including Blitzsafe
`Texas, LLC v. Daimler AG, et al., 2:17-cv-00422. Pet. 3. We observe that
`the litigation is still pending.
`The ’342 patent has been challenged in many AIA proceedings:
`IPR2016-00118, IPR2016-00418, IPR2016-00419, IPR2016-01445,
`IPR2016-01449, IPR2016-01473, IPR2016-01476, IPR2016-01533,
`IPR2016-01557, IPR2016-01560, IPR2018-00090. Pet. 3−4; Paper 6.
`
`The ’342 Patent (Ex. 1001)
`B.
`The ’342 patent is entitled “Multimedia Device Integration System.”
`Ex. 1001, [54]. The ’342 patent describes that a “particular problem with
`integrating after-market audio and video systems with existing car stereo and
`video systems is that signals generated by both systems are in proprietary
`formats, and are not capable of being processed by the after-market system.”
`Id. at 1:54−58. “Thus, in order to integrate after-market systems with
`existing car stereo and video systems, it is necessary to convert signals
`between such systems.” Id. at 1:60−63.
`Certain embodiments of the ’342 patent provide a multimedia device
`integration system that allows “for the wireless integration of a portable
`audio and/or video device with a car audio and/or video system.” Id. at
`5:7−10. “The portable device could comprise a CD changer, CD player,
`satellite receiver (e.g., XM or Sirius), digital media device (e.g., MP3, MP4,
`WMV, or Apple iPod device), video device (e.g., DVD player), or a cellular
`3
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`telephone.” Id. at 5:9−13. In particular, an integration module, which could
`be positioned within the car system, receives data from the portable device
`(including track information, song information, artist information, time
`information, and other related information) and processes the data into a
`format compatible with the car system. Id. at 5:23−30. One embodiment
`illustrated in Figure 19, reproduced below, for example, shows an
`integration subsystem. Id. at 8:3−8.
`
`As shown in Figure 19, integration subsystem 1032 positioned within
`car audio/video system 1010 allows information (data and control signals) to
`
`
`
`4
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`be exchanged between portable device 1024 and car audio/video
`system 1010, and processes and formats data accordingly so that instructions
`and data from car audio/video system 1010 are processed by portable device
`1024, and vice versa. See id. at 33:43–35:62, Fig. 19. Wireless interface
`1016 in the car system and wireless interface 1026 in the portable device
`form wireless link 1022. Id. at 34:15–18; see id. at 35:21–23.
`
`Illustrative Claim
`C.
`Of the challenged claims, claims 49, 73, 97, and 120 are independent.
`Claims 50–57, 62–64, 66, 68, 70, and 71 depend directly or indirectly from
`claim 49. Claims 74−80, 83, 86−88, 94, and 95 depend directly or indirectly
`from claim 73. Claims 98−103, 106, 109−111, 113, and 115 depend directly
`or indirectly from claim 97.
`Claim 49, reproduced below, is illustrative.
`49. A multimedia
`device
`integration
`comprising:
`an integration subsystem in communication with a car
`audio/video system; and
`a first wireless interface in communication with said
`integration subsystem, said first wireless interface establishing a
`wireless communication link with a second wireless interface in
`communication with a portable device external to the car
`audio/video system,
`wherein said integration subsystem obtains, using said
`wireless communication link, information about an audio file
`stored on the portable device, transmits the information to the car
`audio/video system for subsequent display of the information on
`a display of the car audio/video system, instructs the portable
`device to play the audio file in response to a user selecting the
`
`system,
`
`5
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`
`audio file using controls of the car audio/video system, and
`receives audio generated by the portable device over said
`wireless communication link for playing on the car audio/video
`system.
`Ex. 1001, 42:29–47.
`
`Asserted Prior Art and Grounds of Unpatentability
`D.
`The Petition identifies the following references in connection with
`Petitioner’s challenge of unpatentability (Pet. 6−7):
`1) Simonds: U.S. Patent App. Pub. No. 2004/0093155 A1, published on
`May 13, 2004, and filed as Exhibit 1005;
`2) Ekstrom: Document entitled Audio Over Bluetooth and MOST, filed
`as Exhibit 1006;
`3) MOST Specification: Document entitled Media Oriented Systems
`Transport (MOST) Specification Version 2.2-00, filed in the record as
`Exhibit 1007;
`Petitioner asserts one ground of unpatentability (Pet. 5):
`
`Basis
`References
`§ 103(a) Simonds, Ekstrom, and
`MOST Specification
`
`Challenged Claim(s)
`49−57, 62−64, 66, 68, 70, 71, 73-
`80, 83, 86−88, 94, 95, 97, 99−103,
`106, 109−111, 113, 115, and 120
`With regard to introduced testimony, Petitioner relies on the
`Declaration of John M. Strawn, Ph.D. Ex. 1003. Patent Owner relies on the
`Declaration of Richard Stern, Ph.D. Ex. 2001.
`
`6
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`
`II. ANALYSIS
`A. Petitioner’s Burden
`“In an [inter partes review], the petitioner has the burden from the
`onset to show with particularity why the patent it challenges is
`unpatentable.” Harmonic Inc. v. Avid Tech., Inc., 815 F.3d 1356, 1363 (Fed.
`Cir. 2016) (citing 35 U.S.C. § 312(a)(3) (requiring inter partes review
`petitions to identify “with particularity . . . the evidence that supports the
`grounds for the challenge to each claim”)). This burden of persuasion never
`shifts to Patent Owner. See Dynamic Drinkware, LLC v. Nat’l Graphics,
`Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015) (discussing the burden of proof in
`inter partes review). Furthermore, Petitioner cannot satisfy its burden of
`proving obviousness by employing “mere conclusory statements.” In re
`Magnum Oil Tools Int’l, Ltd., 829 F.3d 1364, 1380 (Fed. Cir. 2016).
`Further, in its Motion for Joinder, Petitioner, as the moving party, has
`the burden to establish that it is entited to the relief requested. 37 C.F.R.
`§ 42.20(c). A joinder request is viable only if the inter partes review that
`Petitioner seeks to join has been instituted and is pending at the time of
`joinder. See 35 U.S.C. § 315(c) (“If the Director institutes an inter partes
`review, the Director, in his or her discretion, may join [Petitioner] as a party
`to that inter partes review.”).
`
`B. Denial of Motion for Joinder
`In the Motion for Joinder, Petitioner requests that we institute inter
`partes review and that we join Petitioner as a party to the inter partes review
`requested in IPR2018-00544. Mot. 1. The instant Petition and supportive
`7
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`filings are virtually identical to those filed in IPR2018-00544. Id. at 1−2.
`Patent Owner opposes the Motion for Joinder, arguing that the Petition here
`is
`the 15th petition to seek inter partes review of the ’342 patent, and that
`Petitioner’s request of an alleged “limited” role is prejudicial to Patent
`Owner, given the many reservation of rights and other participatory
`exceptions that Petitioner carved for itself if allowed to join IPR2018-00544.
`Opp’n. 2−3. Patent Owner also argues that Petitioner has not shown a
`legitimate reason for seeking joinder, other than having the same interest in
`common with the Petitioner in IPR2018-00544—seeking unpatentability of
`the ’342 patent. Id. at 4−5.
`In Reply, Petitioner argues that it does not seek the participatory role
`argued by Patent Owner, and that there is no Board rule that prohibits the
`filing of the instant Petition and Motion for Joinder notwithstanding the long
`history of challenges to the ’342 patent. Reply 1. Petitioner reiterates that
`its filings are identical to the filings in IPR2018-00544. Reply 3.
`Although the parties appeal to our exercise of discretion in deciding
`the Motion for Joinder, our determination here hinges on a significant
`procedural defect in Petitioner’s request. Petitioner filed the Motion for
`Joinder, and the instant Petition, before the Board determined whether to
`institute trial in IPR2018-00544. Id. On August 8, 2018, the Board issued a
`Decision Denying Institution in IPR2018-00544. Decision, Jaguar Land
`Rover North America v. Blitzsafe Texas, IPR2018-00544, Paper 8 (PTAB).
`There was no Request for Rehearing of that Decision filed, and the time
`allotted for such a filing has lapsed. Accordingly, there is no ongoing inter
`8
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`partes review to which the instant Petitioner could be joined. Under
`§ 315(c), therefore, we deny the Motion for Joinder.
`Our analysis now proceeds on the merits of the Petition here, which as
`indicated above, is virtually identical to the Petition in IPR2018-00544. The
`analysis that follows below is consistent with the analysis we have
`previously provided regarding the asserted grounds.
`
`Summary of Asserted References
`C.
`(1) Simonds (Exhibit 1005)
`Simonds is directed to a system for providing information on a
`vehicle, and, more specifically, to integrated electronics systems that provide
`enhanced vehicle information services onboard a vehicle. Ex. 1005 ¶ 2.
`Figure 2 of Simonds is reproduced below.
`
`
`
`9
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`
`Figure 2 illustrates an example of various electronic host devices
`included with an infotaiment system providing entertainment and telematics
`services onboard a vehicle. Id. ¶ 37. Vehicle Consumer Services Interface
`(“VCSI”) 30 is a host platform that interfaces with the various electronic
`host devices within the vehicle. Id. VCSI 30 couples to vehicle data bus 20,
`high speed media oriented system transport (“MOST”) bus 44, and wireless
`link 46. Id. VCSI host platform 30 serves as the “bridge between different
`protocols to provide a standardized interface that makes the task of creating
`in-vehicle applications easy, and further serves to synchronize non-
`automotive technology devices to that of the vehicle 10.” Id. ¶ 38.
`With regard to MOST bus 44, it is a wire bus connected in
`communication with electronic devices, including main visual Human
`Machine Interface (“HMI”) 12. Id. ¶ 40. Other electronic devices connected
`to MOST bus 44 include radio tuner 34, audio amplifier 36, compact
`disc/digital versatile disc (“CD/DVD”) player 38, navigation system 40, and
`a global positioning system (“GPS”) receiver 42. Id. The high-speed
`MOST bus allows data communications between each of the electronic host
`devices coupled to MOST bus 44 and VCSI host platform 30. Id.
`With regard to wireless devices, VCSI host platform 30 is able to
`communicate with various wireless devices including cell phone 48,
`personal digital assistant (“PDA”) 50, and media player (e.g., MPEG1 audio
`layer 3 “MP3” player) 52, via wireless link 46. Id. ¶ 41. Simonds explains
`
`
`1 Motion Pictures Experts Group.
`
`10
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`that a user of a cell phone, PDA, MP3 player and keyfob 51 may travel in
`and out of the vehicle and communicate with the vehicle via wireless link
`46. Id. Simonds also states that “[i]t should also be appreciated that a user
`may interface with any of the wireless devices (e.g., cell phone) via any of
`the HMIs 12, 22, and 32 communicating via the VCSI host platform 30.” Id.
`(2) Ekstrom (Exhibit 1006)
`Ekstrom is a thesis that describes a design of a gateway between
`Bluetooth and MOST technologies. Ex. 1006, 1. The gateway “shall be
`able to handle control data to initiate a synchronous link and to route
`synchronous audio sent from Bluetooth to MOST.” Id. Ekstrom first
`defines the audio source because “the gateway needs to know the
`preferences of the audio source.” Id. at 33. One requirement of the audio
`source is the “possibility to send control data that establishes a synchronous
`connection for transferring voice data.” Id. Ekstrom describes the use of
`the Headset (HS) Profile of the Bluetooth specification as it fulfills the
`requirement and fits as an audio source. Id. In Figure 27, reproduced
`below, Ekstrom illustrates how a headset and the audio gateway
`communicate, using attention (“AT”) commands to establish a Bluetooth
`connection.
`
`11
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`
`
`Figure 27 depicts the establishment of a connection between the
`Bluetooth headset (HS) and the Bluetooth audio gateway (AG). According
`to Ekstrom, pressing of the headset button causes the headset to issue an AT
`command (AT+CKPD2=200), which the Bluetooth audio gateway
`understands and responds with an acknowledgement (“OK”). Id.
`Ekstrom recognized that a design problem is the differences between
`transmission of synchronous audio and control data. Id. at 35. Specifically,
`“[f]or synchronous audio the transmission is in the link layer but for the
`control data the approach is to design an interpreter on the application level.”
`Id. Accordingly, Ekstrom adopts the approach of an “interpreter that
`
`
`2 Generally, a keypad emulator on a device.
`12
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`handles the used Bluetooth profile procedure and converts them to the
`corresponding MOST procedures.” Id. at 36. Figure 30, reproduced below
`illustrates the gateway structure.
`
`
`
`Figure 30 depicts the Bluetooth-MOST gateway structure. Id. In
`particular, Ekstrom explains Figure 30 as showing that the interpreting
`application at the “gateway handles the actual Bluetooth profile and
`interprets it to functions and methods understandable by the MOST network
`nodes.” Id. With regard to the data transfer involved in sending audio from
`Bluetooth to MOST, Ekstrom states that first the “connection has to be
`established using control data,” and, subsequently, “the stream of
`synchronous audio is transferred.” Id. “The data in both cases has to be
`modified to fit the other system.” Id.
`More specifically with regard to the control data, Ekstrom explains
`that the headset profile in the headset talks to the headset profile in the
`gateway and the gateway interprets the commands so that the MOST system
`makes the connection independently of what happens on the Bluetooth side.
`Id. at 37; see also 46 (“The gateway has to be programmed so that the
`command sent from Bluetooth gets interpreted correctly on MOST and that a
`Bluetooth command from MOST gets interpreted to the correct command.”).
`
`13
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`
`(3) MOST Specification (Exhibit 1007)
`“This document specifies the MOST system services, which are
`needed to develop MOST Devices, i.e. hardware using MOST technology.”
`Ex. 1007, 15. The MOST Specification describes that a MOST Device
`contains multiple components, which are called function blocks, such as
`“tuner, amplifier, or CD player.” Id. at 19. Each function block, in turn,
`contains a number of single functions, such as “Play, Stop, Eject, and
`Played” (single functions) for a CD player (function block). Id. Each
`function and function block has an identifier (“ID”). Id. at 20.
`Further, the MOST Specification describes the “protocol structure”
`for communication between MOST Devices. Id. at 55−58. For instance, the
`CD Changer with a physical MOST address “CDC,” has a function block
`“CD Player,” and various functions, one of which is “track.” Id. at 57. For
`an HMI to change the track in the CD Player, the HMI sends a protocol
`addressed to the CDC: CDC.CD.1.Track.Set(10). Id. This protocol is
`transmitted from the HMI NetServices to the MOST transceiver of the HMI,
`
`14
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`which communicates the protocol on the MOST bus for receipt by the
`MOST transceiver of the node of the CDC. Id. at 56.
`Figure 2−22 of Ekstrom illustrates how a controller, such as an HMI,
`communicates with the CDC when using the “Next Track” button on the
`HMI.
`
`
`
`Figure 2−22 illustrates the controlled properties in the control device. For
`example, upon selecting the “Next Track” button, the HMI “takes the
`contents of its local variable Track, increments it by one, and sends the
`protocol CD.0.Track.Set(Track+1) to device CDC.” Id. at 61. “After the
`player has changed track, it replies by sending protocol
`CD.0.Track.Status(3).” Id.
`Intelligent MOST devices contain their entire functionality and must
`support all method and properties of NetBlock and MOST Device. Id. at 31
`(stating that “functionality” means the device includes a MOST chip with
`the properties NodeAddr and Logical Addr). A NetworkMaster contains the
`
`15
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`central registry, which represents an image of the physical and logical
`system configuration. Id. at 67 (explaining that the registry includes each
`device’s function blocks: FBlock IDs).
`
`D.
`
`Alleged Obviousness of Independent Claims 49, 73, 97, and 120
`The “integration subsystem” recited in claims 49, 73, and 120
`“instructs the portable device to play the audio file in response to a user
`selecting the audio file using controls of the car audio/video system.” See
`Ex. 1001, 42:42−44 (“the instruction limitation”).
`Petitioner contends that the combination of Simonds, Ekstrom, and
`the MOST Specification teaches the “integrated subsystem.” Pet. 28−35. In
`particular, Petitioner relies on Simonds’s VCSI acting “as the Network
`Master described in the MOST Specification and includes the Ekstrom
`MOST/Bluetooth gateway.” Pet. 28. With regard to the instruction
`limitation, Petitioner argues that
`(1) Simonds’s VCSI interfaces off-board devices and HMIs;
`(2) A person of ordinary skill in the art would understand that the
`VCSI instructs the portable device to perform an action in response
`to a user selection on the HMI;
`(3) A person of ordinary skill in the art would have found it obvious to
`implement the VCSI to instruct the portable to play the audio file
`in response to a user selecting the audio file using the HMI
`controls as disclosed in the MOST Specification;
`(4) The MOST Specification discloses that the “Player” device
`includes the play or next function block;
`16
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`
`(5) The Network Master of the MOST Specification or Simonds’s
`VCSI has a central registry of each function block associated with
`a device;
`(6) A user can use the HMI function block to use the play or next
`function block of a “Player” portable device;
`(7) Through an abstract method, a CD player could be set to mode
`“Play” by “SourceActivity.Start(On);”
`(8) The MOST Specification discloses an example of using “Next
`track” button with a protocol CD.0.Track.Set(Track+1);
`(9) A person of ordinary skill in the art would understand that a
`portable device (Simonds’s MP3 player) would respond to MOST
`commands (“Play” and “Next Track”) from the Network
`Master/VCSI as disclosed in the MOST Specification. Pet. 42−44.
`Patent Owner challenges Petitioner’s arguments and evidence with
`regard to the instruction limitation. Prelim. Resp. 20−31. In particular, to
`address argument (1) above, Patent Owner argues that Simonds does not
`teach issuing commands from the VCSI to the MP3 player in response to a
`user selecting an audio file. Id. at 20. We agree. Simonds describes the
`VCSI’s ability to interface the devices, but is silent as to how the devices
`communicate with the VCSI.
`As to Petitioner’s argument (2), Petitioner relies on the Strawn
`Declaration to fill Simonds’s gap in this regard. Pet. 42−43 (citing Ex. 1003
`¶¶ 161−67). The factual support for Strawn’s assertion that Simonds’s VCSI
`“instructs the portable device” is that: (a) Simonds “interfaces” various
`devices; and (b) that the VCSI host platform is “able to communicate with
`17
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`various wireless devices.” Ex. 1003 ¶ 162. We are not persuaded by the
`testimony as it ascribes to Simonds the ability to control an MP3 player from
`the HMI connected to the MOST bus when Simonds neither describes nor
`implies such functionality. The facts presented to us do not appear to
`support the conclusion that Simonds performs the “instruction limitation”
`based on the generic statements of Simonds’s VCSI communicating with or
`interfacing the wireless device.
`With respect to Petitioner’s arguments (3)−(9), as to whether the
`MOST Specification provides the details of the communications between the
`HMI−VCSI−MP3 player, Patent Owner argues that the MOST Specification
`“only discloses how one MOST device can transmit commands to control
`another MOST device where both devices are built into a vehicle.” Id. at 23.
`We agree with Patent Owner that the MOST Specification details the
`manner in which MOST devices, such as the CD Player, are controlled by an
`HMI in a MOST bus.
`However, Petitioner relies on the MOST Specification to argue that
`the MP3 player would understand the disclosed commands, in the same
`manner the CD Player is shown to understand them. Pet. 44 (see argument
`(9) listed above). But there is no evidence of a portable device, such as an
`MP3 player that would have both MOST and Bluetooth capabilities, so that
`the purported combination of teachings would work as the claims require.
`Upon further study of the Petition we note an explanation in the
`Strawn Declaration that the MOST network architecture, which follows
`object-oriented programming, allows for the “functionality of a program” to
`be broken down into a collection of objects. Ex. 1003 ¶ 65. Thus the
`18
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`Strawn Declaration provides, “The functionality could represent for example
`the MP3 player’s ability to start and stop playing a song, or selecting a
`song.” Id (emphasis added). We find this is insufficient to show how the
`combination of teachings would work as asserted.
`First, for the combination of teachings to work predictably, the MP3
`player (or any other devices coupled to the wireless link) must be a MOST
`device or, at a minimum, have the MOST functionality to receive the
`protocols and methods that Petitioner asserts would work to issue “Play” or
`“Next Track” instructions. The record lacks persuasive evidence of any
`such device. Nor has Petitioner asserted how a typical MP3 player, such as
`the one shown in Simonds, would be modified to include the MOST
`functionality, in addition to the Bluetooth functionality.
`Second, if Petitioner is not relying on a portable device with the
`functionality of a MOST device, then it must show how the VCSI/Network
`Manager, or any other alleged “interface,” would translate the
`protocols/methods (“Play” or “Next Track”) from the MOST Specification
`into commands that the wireless portable device would understand. The
`record contains no such evidence. At best, Ekstrom teaches that an
`“interpreting application” is used to translate, into MOST, the Bluetooth
`control data needed to establish a communication link. There is no evidence
`that a MOST protocol for “Play” would have been translated into a
`Bluetooth command that the MP3 player of Simonds would understand.
`Indeed, the Bluetooth Headset Profile of Ekstrom does not allow for either a
`“Play” or “Next Track” command. Thus, even if Petitioner had relied on
`Ekstrom for the “instruction limitation,” which it did not, Ekstrom does not
`19
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`teach or suggest that the gateway would have interpreted a MOST protocol
`for “Play” or “Next Track” into a corresponding Bluetooth command.
`Third, the motivation to combine Simonds and the MOST
`Specification is too generic and insufficient for us to be persuaded. See
`ActiveVideo Networks Inc. v. Verizon Comm., Inc., 694 F.3d 1312, 1328
`(Fed. Cir. 2012) (finding expert testimony of motivation to combine “to
`build something better,” “more efficient, cheaper, or” something that “had
`more features” was generic and insufficient). Petitioner asserts, for instance,
`that the generic goal of providing a single, cohesive system would have been
`a reason to combine the teachings of Simonds and the MOST Specification.
`Pet. 25. As further reasons, Petitioner asserts that the combination would
`result in the user having an enhanced vehicle experience, safer driving
`experience, and predictable results because both Simonds and the MOST
`Specification use the MOST bus. Id. at 25−26.
`Again, these assertions are generic and bear little relation to any
`specific combination of elements. According to the ActiveVideo court, such
`generalizations “fail[] to explain why a person of ordinary skill in the art
`would have combined elements from specific references in the way the
`claimed invention does.” ActiveVideo, 694 F.3d at 1328 (emphasis added).
`None of the proffered reasons address why the Simonds MP3 player would
`have been designed to include MOST functionality in addition to Bluetooth,
`or why a person of ordinary skill in the art would have added programming
`to the VCSI to include an MP3 player object that understands CD Player
`commands, or how a gateway would have been designed to translate MOST
`
`20
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`commands to Bluetooth in order to control the play functions of an MP3
`player.
`For at least the foregoing reasons, we are not persuaded that Petitioner
`has shown sufficiently that the asserted combination of references teaches
`the “instruction limitation” or that a person of ordinary skill in the art would
`have had a reason to combine Simonds and the MOST Specification as
`asserted for this limitation. Accordingly, we determine that Petitioner has
`not shown a reasonable likelihood that claims 49, 73, and 120 would have
`been obvious over Simonds, Ekstrom, and the MOST Specification.
`
`Alleged Obviousness of Claim 97
`E.
`Claim 97 recites the “integration subsystem” to “receive[] a control
`command issued by a user through one or more controls of the car
`audio/video system in a format incompatible with the portable device,
`processes the control command into a formatted command compatible with
`the portable device, and dispatches the formatted command to the portable
`device for execution thereby.” Ex. 1001, 45:57−63 (the “control command
`limitation”). Petitioner relies on Simonds, the MOST Specification, and
`Ekstrom as teaching the limitation. In particular, Petitioner argues that
`Simonds’s VCSI receives an “audio command input” from the HMI and that
`the command is in a format incompatible with the portable device. Pet. 47
`(citing Ex. 1005 ¶¶ 35−36). Petitioner alleges that Simonds’s VCSI is a
`“bridge” between different protocols and enables compatibility between
`devices provided by a variety of different suppliers. Id. (citing Ex. 1005
`¶ 38 and what appears to be the analysis provided for the “instruction
`21
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`limitation” discussed above). However, Petitioner relies on the details
`taught in the MOST Specification and Ekstrom, explained above with
`respect to the “instruction limitation” of how the MOST Specification
`discloses a “Next Track” command issued to the CD Player and that
`Ekstrom translates control data from “MOST language to Bluetooth.” Id. at
`47−49.
`We do not repeat the analysis discussed above, but reiterate that
`Petitioner does not show how the VCSI/Network Manager, or any other
`alleged “interface,” would translate the protocols/methods (“Play” or “Next
`Track”) from the MOST Specification into commands that the wireless
`portable device would understand. Claim 97 expressly requires that the
`command issued by the car/audio video system is incompatible with the
`portable device. And as stated above, at best, Ekstrom teaches that an
`“interpreting application” is used to translate, into MOST, the Bluetooth
`control data needed to establish a communication link between a headset and
`a MOST audio/speaker device. But there is no evidence that a MOST
`protocol for “Play” would have been translated into a Bluetooth command
`that the MP3 player of Simonds would understand. The Bluetooth Headset
`Profile of Ekstrom does not allow for either a “Play” or “Next Track”
`command. Thus, the Petition fails to show that Ekstrom teaches or suggests
`a gateway that would have interpreted a MOST protocol for “Play” or “Next
`Track” into a corresponding Bluetooth command.
`As stated above, the motivation to combine Simonds and the MOST
`Specification is too generic and the motivation to combine with Ekstrom
`also is too generic and insufficient. See ActiveVideo, 694 F.3d at 1328.
`22
`
`
`
`IPR2018-01209
`Patent 8,155,342 B2
`
`Petitioner states that it would have been obvious to implement formatting
`data and commands for wireless transmission as described in Ekstrom
`because of the goal of integrating wireless devices to a car audio/video
`system and the general benefits of using Bluetooth. Pet. 26−27. For
`instance, Petitioner alleges that Bluetooth allows seamless audio channeled
`to the car audio/video system, avoids cables, is “less cumbersome to the
`user,” saves costs, avoids delay of playback that might result from sending
`entire audio files. Id. at 26.
`Petitioner finally alleges that implementing Bluetooth and MOST as
`alleged would provide predictable results because Simonds and Ekstrom
`describe their use. Id. at 26−27. All of these assertions are generic and bear
`little relation to any specific combination of elements. The benefits derived
`from using Bluetooth generally do not speak to the reasons a person of
`ordinary skill in the art would implement translation of certain commands
`issued by the car/audio video system using a MOST protocol into the
`Bluetooth standard in order to control the wireless MP3 player.
`Rather, the reasons provided for the implementation of Ekstrom’s
`teachings with Simonds’s system contradict the reasons provided for the
`other independent claims, for which Petitioner contends no translation of
`commands would be necessary. See, e.g., Ex. 1003 ¶ 166 (Strawn opining
`that a “POSA would understand that a portable device such as Simonds MP3
`player 52 would respond to MOST commands such as play and
`stop discussed above for the CD player and as disclosed in the MOST
`Specificat