throbber
Paper 10
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket