Trials@uspto.gov
`571-272-7822
`
`Paper 8
`Entered: August 10, 2018
`
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`JAGUAR LAND ROVER NORTH AMERICA, LLC and JAGUAR LAND
`ROVER LTD.,
`Petitioner,
`
`v.
`
`BLITZSAFE TEXAS, LLC,
`Patent Owner.
`____________
`
`Case IPR2018-00544
`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
`37 C.F.R. § 42.108
`
`
`
`
`
`
`571-272-7822
`
`Paper 8
`Entered: August 10, 2018
`
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`JAGUAR LAND ROVER NORTH AMERICA, LLC and JAGUAR LAND
`ROVER LTD.,
`Petitioner,
`
`v.
`
`BLITZSAFE TEXAS, LLC,
`Patent Owner.
`____________
`
`Case IPR2018-00544
`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
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`
`I.
`
`INTRODUCTION
`
`Petitioner, as captioned above, filed a Petition requesting an inter
`
`partes review of claims 49–57, 62–64, 66, 68, 70, 71, 73–80, 83, 8688, 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 3
`
`(“Pet.”). Patent Owner filed a Preliminary Response. Paper 7 (“Prelim.
`
`Resp.”).
`
`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.” Having considered the Petition and the Preliminary Response, and
`
`for the reasons stated below, we do not institute inter partes review.
`
`A.
`
`Related Matters
`
`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. Jaguar Land Rover Ltd., 2:17-cv-00424. Pet. 2. 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. 34; Paper 6.
`
`2
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`
`B.
`
`The ’342 Patent (Ex. 1001)
`
`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:5458. “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:6063.
`
`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:710. “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
`
`telephone.” Id. at 5:913. 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:2330. One embodiment
`
`illustrated in Figure 19, reproduced below, for example, shows an
`
`integration subsystem. Id. at 8:38.
`
`3
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`
`
`
`As shown in Figure 19, integration subsystem 1032 positioned within
`
`car audio/video system 1010 allows information (data and control signals) to
`
`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.
`
`4
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`
`C.
`
`Illustrative Claim
`
`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 7480, 83, 8688, 94, and 95 depend directly or indirectly
`
`from claim 73. Claims 98103, 106, 109111, 113, and 115 depend directly
`
`or indirectly from claim 97.
`
`Claim 49, reproduced below, is illustrative.
`
`49. A multimedia device integration system, 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
`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.
`
`5
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`
`D.
`
`Asserted Prior Art and Grounds of Unpatentability
`
`The Petition identifies the following references in connection with
`
`Petitioner’s challenge of unpatentability (Pet. 67):
`
`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):
`
`Challenged Claim(s)
`
`Basis
`
`References
`
`4957, 6264, 66, 68, 70, 71, 73-
`80, 83, 8688, 94, 95, 97, 99103,
`106, 109111, 113, 115, and 120
`
`§ 103(a)
`
`Simonds, Ekstrom, and
`MOST Specification
`
`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.
`
`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
`
`6
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`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, the Federal Circuit warns that “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) (emphasis added).
`
`B.
`
`Summary of Asserted References
`
`(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.
`
`7
`
`
`
`IPR2018-00544
`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
`
`8
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`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
`
`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
`
`
`
`1 Motion Pictures Experts Group.
`
`9
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`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.
`
`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
`
`
`
`10
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`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
`
`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
`
`
`
`2 Generally, a keypad emulator on a device.
`
`11
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`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.”).
`
`(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 5558. 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, which communicates the
`
`12
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`protocol on the MOST bus for receipt by the MOST transceiver of the node
`
`of the CDC. Id. at 56.
`
`Figure 222 of Ekstrom illustrates how a controller, such as an HMI,
`
`communicates with the CDC when using the “Next Track” button on the
`
`HMI.
`
`
`
`Figure 222 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
`
`13
`
`
`
`IPR2018-00544
`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).
`
`C.
`
`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:4244 (“the instruction limitation”).
`
`Petitioner contends that the combination of Simonds, Ekstrom, and
`
`the MOST Specification teaches the “integrated subsystem.” Pet. 2835. 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. 29. 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;
`
`14
`
`
`
`IPR2018-00544
`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. 4344.
`
`Patent Owner challenges Petitioner’s arguments and evidence with
`
`regard to the instruction limitation. Prelim. Resp. 2031. 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 21. 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. 41 (citing Ex. 1003
`
`¶¶ 16167). 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
`15
`
`
`
`IPR2018-00544
`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
`
`HMIVCSIMP3 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
`
`16
`
`
`
`IPR2018-00544
`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
`
`17
`
`
`
`IPR2018-00544
`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 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
`
`18
`
`
`
`IPR2018-00544
`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.
`
`D.
`
`Alleged Obviousness of Claim 97
`
`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:5763 (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 ¶¶ 3536). 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
`
`19
`
`
`
`IPR2018-00544
`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
`
`4749.
`
`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.
`
`20
`
`
`
`IPR2018-00544
`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. 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 2627.
`
`Petitioner finally alleges that implementing Bluetooth and MOST as
`
`alleged would provide predictable results because Simonds and Ekstrom
`
`describe their use. Id. at 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
`
`Specification”); but see ¶ 190 (Strawn opining that the “command received
`
`from the MOST HMI would be in a format incompatible with the portable
`
`21
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`device” and stating that Ekstrom’s “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.”).
`
`The Petition and the Strawn Declaration vacillate between these
`
`positions depending on the claim addressed, evidencing the strong inference
`
`that hindsight is at play. The Strawn Declaration without sufficient
`
`explanation and without credible support states that Simonds’s MP3 player
`
`“may communicate not only with Bluetooth but also via wire such as
`
`MOST.” Ex. 1003 ¶ 97. The cite to Simonds does not support this assertion
`
`as there is no disclosure in Simonds that an MP3 player would have had both
`
`Bluetooth and MOST functionalities. Nevertheless, the assertion belies
`
`Petitioner’s contentions of obviousness that an MP3 player would require
`
`translation of commands (claim 97) received from a MOST device of the car
`
`stereo, as the same MP3 player, according to Petitioner, for claims 43, 73,
`
`and 120, could understand the MOST commands.
`
`For at least the foregoing reasons, we are not persuaded that Petitioner
`
`has shown sufficiently that the asserted combination of references teaches
`
`the “control command limitation” or that a person of ordinary skill in the art
`
`would have had a reason to combine Simonds, the MOST Specification, and
`
`Ekstrom as asserted for this limitation. Accordingly, we determine that
`
`Petitioner has not shown a reasonable likelihood that independent claim 97
`
`would have been obvious over Simonds, Ekstrom, and the MOST
`
`Specification.
`
`22
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`
`Accordingly, it is:
`
`III. ORDER
`
`ORDERED that the Petition is denied and no inter partes review is
`
`instituted.
`
`.
`
`
`
`23
`
`
`
`IPR2018-00544
`Patent 8,155,342 B2
`
`PETITIONER:
`
`
`Matthew J. Moore
`Jonathan M. Strang
`Clement Naples
`Lisa K. Nguyen
`matthew.moore@lw.com
`jonathan.strang@lw.com
`clement.naples@lw.com
`lisa.nguyen@lw.com
`
`
`
`
`
`
`PATENT OWNER:
`
`Peter Lambrianakos
`Vincent J. Rubino, III
`Enrique W. Iturralde
`plambrianakos@brownrudnick.com
`vrubino@brownrudnick.com
`eiturralde@brownrudnick.com
`
`
`
`24
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
