UNITED STATES PATENT AND TRADEMARK OFFICE
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`SONOS, INC.
`Petitioner
`
`v.
`
`IMPLICIT, LLC
`Patent Owner
`
`IPR2018-00767 (Patent 8,942,252 B2)
`
`PATENT OWNER’S RESPONSE TO INSTITUTION OF INTER PARTES
`REVIEW OF U.S. PATENT NO. 8,942,252
`
`
`
`
`
`
`
`
`
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`
`
`TABLE OF CONTENTS
`
`
`TABLE OF AUTHORITIES .......................................................................................................... ii
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`I.
`
`INTRODUCTION .........................................................................................................1
`
`II.
`
`BACKGROUND ...........................................................................................................1
`
`
`
`
`
`A. Implicit and the Development of the Inventions of the ’252 Patent ..................1
`
`B. The ’252 Patent ..................................................................................................7
`
`C. The Alleged Prior Art References ......................................................................9
`
`1. The Base Reference: Janevski ............................................................10
`
`2. The Secondary References: Azevdeo, Mills,
`Berthaud, and Eidson .........................................................................12
`
`D. The Petition and the Institution Decision .........................................................13
`
`III.
`
`CLAIM CONSTRUCTION .........................................................................................13
`
`IV. ARGUMENT ...............................................................................................................14
`
`
`A. Janevski is Not Prior Art ..................................................................................14
`
`
`1. How Strings Operated in 2001 ...........................................................16
`
`2. Prior to December 11, 2001, the Inventors Conceived
`of the Challenged Claims and Reduced Them to Practice .................19
`
`
`
`
`
`
`
`V.
`
`3. The Source Code Corroborates That the Inventions
`Were Actually Reduced to Practice Prior to December 11, 2001 .....29.
`
`B. Even if Janevski is Prior Art, the References Do Not
`Render the ’252 Patent Claims Obvious ..........................................................31
`
`1. The Petition Fails to Make a Prima Facie Case .................................32
`
`2. Objective Evidence of Nonobviousness Shows
`That the Claims Would Not Have Been Obvious ..............................35
`
`3.
`
`Janevski Fails to Disclose a “Master Device Time,” as Recited in
`Claim 2 ...............................................................................................38
`
`CONCLUSION ............................................................................................................40
`
` i
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`
`
`
`TABLE OF AUTHORITIES
`
`
`
`Cases
`
`Cooper v. Goldfarb,
`
`154 F.3d 1321 (Fed. Cir. 1998) .............................................................. 14, 15
`
`KSR Int’l Co. v. Teleflex Inc.,
`
`550 U.S. 398, 405 (2007) ............................................................................. 33
`
`NFC Tech., LLC v. Matal,
`
`871 F.3d 1367 (Fed. Cir. 2017) ................................................................... 15
`
`Slip Track Sys. v. Metal-Lite, Inc.,
`
`304 F.3d 1256 (Fed. Cir. 2002) ................................................................... 14
`
`Transocean Offshore Deepwater Drilling, Inc. v. Maersk Drilling USA, Inc.,
`699 F.3d 1340 (Fed. Cir. 2012) ................................................................... 35
`
`
`
`
`
`
`ii
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`I.
`INTRODUCTION
`
`The Board should conclude that the Challenged Claims in this proceeding are
`
`patentable. The Petition hinges on a reference, Janevski, that is not prior to the ’252
`
`Patent. Implicit can swear behind Janevski, which concludes these proceedings in
`
`Implicit’s favor. But, even if Janevski is prior art, the Petition has failed to show
`
`that it invalidates the Challenged Claims because the Petition does not make out a
`
`prima facie showing of obviousness and Implicit has presented objective evidence
`
`of nonobviousness that further preclude a finding of obviousness here. For these
`
`reasons and the reasons below, Implicit respectfully requests that the Board find
`
`patentable the ’252 Patent claims.
`
`II. BACKGROUND
`
`A.
`
`Implicit and its Development of the Inventions of the ’252 Patent
`
`The inventions in this proceeding flow from work that lead inventor Edward
`
`Balassanian conducted at the company he founded, BeComm (now Implicit). In
`
`1995, Mr. Balassanian, then in his 20s, left a secure job at Microsoft to start his own
`
`company. Ex. 2001, at ¶ 8. He founded BeComm in 1996. Id.
`
`Mr. Balassanian founded BeComm to build a new type of operating system
`
`that could allow any application or device to interact with any other application or
`
`device. Ex. 2001, at ¶ 9. That goal led Mr. Balassanian to re-define how computing
`
`devices operated, which required re-architecting a new type of operating system
`
`from the ground up. Id. He called the new operating system Portal (which then
`
`
`
`1
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`became Strings), and his work relating to BeComm resulted over 25 U.S. Patents.
`
`Id. at ¶¶ 10, 14. This proceeding involves one of those patents.
`
`In the traditional systems in the 1990s, the operating system interacted with
`
`the drivers for the hardware and then, using fixed, defined pathways, relayed the data
`
`for an application to use. Ex. 2001, at ¶¶ 11–13. Strings was a fundamentally
`
`different architecture. Id. at ¶ 14. It could, on-the-fly, provide a data flow from any
`
`source to any destination and provide the data in a format that the destination could
`
`consume or use. Id.
`
`The operating system accomplished that result by utilizing “beads” to process
`
`information instead of the fixed processing pathways. Ex. 2001, at ¶ 15. A “bead”
`
`was a routine or set of routines that could manipulate computer information, id., such
`
`as decoding mp3 audio, Ex,. 2076, displaying RGB video on a display device, Ex.
`
`2050, or sending audio to a speaker for playback, Ex. 2051. The system worked by
`
`“stringing” together these “beads” to process data from a source to a destination. Ex.
`
`2001, at ¶¶ 11–13; see, e.g., Ex. 2002, at 6–9.
`
`BeComm had an internal prototype of some Strings functionalities by the fall
`
`of 1998. Ex. 2001, at ¶ 18. Mr. Balassanian demonstrated various multimedia
`
`functionalities of Strings in February 2000 at the DEMO 2000 conference, including
`
`using Strings to stream video from a VCR cassette onto a handheld device. Id. at ¶¶
`
`18–20. Strings won Best in Show at DEMO 2000. Id. at ¶ 18.
`
`
`
`2
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`The Patent at-issue in this case arose from multimedia functionality within
`
`Strings. Starting at least by the 2000 time period, one focus of Strings was media
`
`processing and functionality. One of BeComm’s early, major relationships was with
`
`Intel have Strings as the software for the Intel Web Tablet (or “iPAD”), an internal
`
`project at Intel. Ex. 2001, at ¶ 22.
`
`One key application of Strings was that it could render on the Intel Web Tablet
`
`content stored on the user’s personal computer (“PC”) or content streamed from over
`
`the Internet. Ex. 2001, at ¶ 25. The Intel Web Tablet connected to a user’s PC. Id.
`
`Running on the user’s PC and on the Tablet, Strings would retrieve the content from
`
`the PC, process the content and convert it into a format to play back on the Tablet,
`
`transmit the content to the Tablet, and then render the media on the Tablet. Id.
`
`Strings also could, through the PC, retrieve content from the Internet and render that
`
`content onto the Tablet, such as streaming Internet radio.
`
`
`
`3
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`With Strings on the iPAD, BeComm explained on a webpage in 2001, users
`
`could “enjoy digital audio on the tablet by playing MP3s stored on their PC or by
`
`listening to Internet radio from anywhere in the home”:
`
`
`By the time of the Intel Web Tablet project, Strings was able to stream audio
`
`Ex. 2006.
`
`
`
`and video content from one source to multiple output devices. Ex. 2001, at ¶ 26.
`
`One problem that BeComm encountered, however, was that the content was not
`
`synchronized for a number of reasons primarily dealing with differences in the
`
`transmission and processing delays between devices. Id. at ¶ 28. In late 2000, Intel
`
`
`
`4
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`approached BeComm to develop a solution to stream media to multiple devices. One
`
`requirement was that the audio content would be synchronized. In project
`
`documentation, both
`
`Intel and BeComm
`
`recognized
`
`that
`
`true content
`
`synchronization was an “unsolved computer science problem,” but BeComm would
`
`put forth its best efforts to solve that problem. Id. at ¶ 29–30; Ex. 2009, at 15; Ex.
`
`2010, at 37–38.
`
`The project for Intel went on hold in February 2001, Ex. 2012, but BeComm
`
`continued to work on solving the synchronization problem. Mr. Balassanian and
`
`Scott Bradley, a BeComm Development Manager, solved the synchronization
`
`problem and conceived of the inventions of the ’252 Patent. Ex. 2001, at ¶ 33. They
`
`then worked to reduce the inventions to practice. Working demonstrations of the
`
`invention were operable before December 11, 2001.
`
`BeComm’s internal documents indicate that the inventions were built and
`
`working in the fall of 2001. Initial versions of main beads for synchronization,
`clocksync and timesync, were completed by September 10, 2001, Ex. 2013,
`at 2; Ex. 2030, at 8, and were part of a new package, remotesync, to “test[] remote
`
`synchronization of audio/video over the network,” Ex. 2015, at 3; Ex. 2001, at ¶ 35.
`The first version of the audiosync bead (used as part of synchronizing audio) was
`
`completed by September 28, 2001, and it “work[ed]” using its initial technique.
`
`Exhibit 2016, at 7; Ex. 2001, at ¶ 36.
`
`
`
`5
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`2001
`in October
`packages
`software
`created
`BeComm
`also
`(test/audiosync and test/demo) and in November 2001 (test/demo2) to
`
`test and demonstrate the synchronization inventions. Ex. 2001, at ¶¶ 44–49, 64–69);
`
`Ex. 2031, at 2; Ex. 2032, at 2; Ex. 2034, at 2. These packages were able to
`
`synchronize the rendering of audio (mp3 and PCM) and video across multiple
`
`devices using the inventions. Ex. 2001, at ¶¶ 45–74.
`
`One demonstration that BeComm performed at this time was the “Fight Club”
`
`demo, which synchronized the rendering of the video and audio content from the
`
`trailer for the movie Fight Club on three different devices: a master device that
`
`rendered the video and audio, a slave device that played the video, and a slave device
`
`that played the audio. Id. at ¶¶ 53–60. BeComm also demonstrated the audio
`
`synchronization functionality in the Strings Audio Player in November 2001, which
`
`became part of a software development kit known as the RADkit by December 3,
`
`2001. Ex. 2001, at ¶¶ 64–73. BeComm documents dated between October 4th and
`
`December 3th described the synchronization technology and how it worked. See
`
`generally id. at ¶¶ 61–73.
`
`By December 9, 2001, a document entitled “synchronization.doc” was
`
`complete. Ex. 2037. This document became the provisional patent application filed
`
`on December 17, 2001 to which the ’252 Patent claims priority.
`
`
`
`
`
`
`
`6
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`B.
`The ’252 Patent
`
`The ’252 Patent is directed to a method and system for synchronizing the
`
`rendering of content on multiple networked devices. It allows, for example,
`
`simultaneous playback of audio and/or video on multiple devices. Over the past
`
`several years, the patented technology has achieved remarkable commercial success.
`
`Because the patented technology allows a single content stream to be rendered with
`
`extraordinarily tight synchronization at multiple networked devices, it has been
`
`widely adopted in the wireless, multi-room audio space.
`
`The problem of synchronizing the rendering of content is an old one.
`
`Multimedia presentations, for example, confronted the problems of synchronizing
`
`video, audio, and text. ’791 Patent, col. 1 ll. 22–27.1 If the content is rendered on
`
`one device, synchronization may be possible. The problem becomes more
`
`complicated, however, where multiple devices are used to render content
`
`simultaneously. This is because each rendering device has its own system clock,
`
`which means that each rendering device typically operates in its own “time domain.”
`
`’791 Patent, col. 1 ll. 35–37. The clocks on each of the system’s devices typically
`
`operate on slightly different frequencies, such that the “time domains” of each
`
`rendering device can, over time, drift out of alignment. As a result, the rendering of
`
`
`1 The ’252 Patent is a continuation of the ’791 Patent, which is at-issue in IPR2018-
`00766. Because the ’252 Patent and the ’791 Patent share the share disclosure as a
`continuation application, this Background section will cite to the ’791 Patent
`specification.
`
`
`
`7
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`the content is out of synchronization. If the difference is large enough, a viewer
`
`would perceive that the rendering of the content is not aligned (e.g., by hearing a
`
`noticeable echo for audio playback). Id. at col. 1 ll. 28–42.
`
`The ’791 Patent’s solution to the problem of rendering content simultaneously
`
`on multiple devices (the “rendering devices”) includes methods and systems for
`
`exchanging information or “messages” between the various devices. The messages
`
`exchanged include “device times” and “rendering times.” ’791 Patent, col. 2 ll. 15–
`
`17. A device time is a time indicated by that device’s system clock. Id. A “rendering
`
`time” identifies a specific position in the content stream. It can be the time
`
`represented by the amount of a specific item of content that a rendering device has
`
`rendered. Id. at col. 2 ll. 18–19. Or, it can be an idealized “rendering time” that
`
`identifies a content position that “may not correspond to the actual rendering time of
`
`any of the rendering devices.” Id. at col. 5 l. 65–col. 6 l. 1.
`
`In order to exchange information to synchronize rendering of content, one
`
`device is identified as the “master” device, while the remaining devices are identified
`
`as “slave” devices. ’791 Patent, col. 2 ll. 28–32. Messages are exchanged between
`
`the devices to clearly identify the master device and the slave devices. Id.
`
`In order to synchronize the devices, in one embodiment of the patent, the
`
`master device sends a message to each slave device, including: 1) the master’s
`
`rendering time, and 2) the master’s device time. ’791 Patent, col. 2 ll. 34–36. Each
`
`slave device then determines whether it is synchronized with the master’s rendering
`
`
`
`8
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`time. If not, the slave adjusts its rendering time to adjust for the difference between
`
`the master rendering time and its own rendering time. Id. at col. 2 ll. 39–42.
`
`To make an adjustment, in one embodiment, the slave device exchanges
`
`device time and rendering time information for the master and slave devices, along
`
`with time stamps on the messages for exchanging the information, allowing the
`
`slave device to determine by how much its rendering time is out of alignment with
`
`the master device’s rendering time. The slave device can, for example, compare
`
`the slave rendering time to the master rendering time at a given slave device time.
`
`Or, the slave device can compare the slave device time at a given rendering time to
`
`the master device time at the same rendering time. ’791 Patent, col. 2 ll. 42–48.
`
`The ’791 Patent teaches, in addition to calculating latency using rendering
`
`times and device times, using information from multiple time points to further
`
`assist synchronization. A component can use the stored information to “smooth”
`
`the time domain differentials using various techniques. ’791 Patent, col. 7 ll. 12.
`
`C. The Alleged Prior Art References
`
`This proceeding involves two sets of alleged prior art references: U.S. Patent
`
`No. 7,269,338 (“Janevksi,” attached as Sonos Ex. 1007) and four secondary
`
`references: Azevedo, Mills, Berthaud, and Eidson. The sections below briefly
`
`discuss each reference.
`
`
`
`9
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`1.
`The Base Reference: Janevski
`
`Janevski is directed to the problem of simultaneous playback of digital content
`
`at remote locations that have each recorded and stored their own copy of the content
`
`to be played back. Janevski, at col. 5 ll. 3–10. The digital content streams are pre-
`
`recorded on and played back from Personal Video Recorders (“PVRs”). Janevski
`
`purports to allow multiple viewers to simultaneously view pre-recorded content in
`
`their respective homes simultaneously with one another, and to rewind or fast-
`
`forward content at remote locations while maintaining simultaneous viewing for all
`
`viewers. Id. at col. 5 ll. 16–19; col. 5 ll. 22–26.
`
`The primary manner in which Janevski addresses the problem of simultaneous
`
`playback is content-based synchronization. “To achieve precise synchronization,
`
`the present invention compares corresponding content or ‘landmarks’ of pairs of
`
`video playbacks to be synchronized, determines video replay ‘distance’ between the
`
`landmark pairs, and slows downs or speeds up selected playbacks in accordance with
`
`these distances.” Janevski, col. 3 ll. 52–57. Janevski allows remote devices to
`
`exchange information about rendering time to facilitate its content matching. All
`
`calculations are based solely on rendering times.
`
`Two or more users may participate in a viewing session. The first user to play
`
`given content is the “initiator” device, while the remaining devices are “participant
`
`devices.” Janevski, at col. 6 ll. 16–21. An initiator device can be a participant
`
`device, and a participant device can be an initiator device. Id. at col. 6 ll. 22–23. If,
`
`
`
`10
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`for example, a user of a participant device performs an operation on the streamed
`
`content, such as fast-forward, the participant device becomes the “initiator” device
`
`for that operation. Id. at col. 6 ll. 23–25. Accordingly, “initiator/participant” is not
`
`a persistent designated status, but rather a status that is conditional on a given
`
`operation.
`
`To synchronize playback, an initiator device sends a message to participant
`
`devices. The message includes a time stamp from the “video timer,” which is the
`
`rendering time of the video or digital stream. Janevski, at col. 7 ll. 41–47, col. 9 ll.
`
`15–29. The participant notes the time the message was received on its own video
`
`timer, and sends a reply including the time of the reply message according to that
`
`video timer. Id. at col. 9 ll. 21-27, col. 10 ll. 10–17. The initiator notes the time of
`
`receipt as measured by its own video timer. Id. at col. 10 ll. 17–18. Using this set
`
`of rendering times, the initiator device can calculate time delays in the rendering of
`
`content between initiator and participant devices. Ex. 1007, at col. 12:18-29.
`
`The initiator device, having calculated the time delay between the rendering
`
`times of the initiator and participant devices, also selects a “query frame.” The query
`
`frame is a “frame that the initiator device has just played or has recently played, so
`
`that the content of the query frame and its respective time stamp represent where the
`
`playback is in the content at a particular time which is current.” Janevski, at col. 12
`
`ll. 5–11.
`
`
`
`11
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`The initiator then sends messages to the participant devices including the time
`
`misregistration, query frame time stamp, and other information. Janevski, at col.
`
`12:30-36. Upon receiving the message including time misregistration, the
`
`participant PVR may advance or rollback the playing of video to compensate for the
`
`time misregistration. Id. at col. 12 ll. 50–56.
`
`To accomplish synchronization, the participant device uses the information
`
`sent by the initiator device to calculate the “frame misregistration.” That value is
`
`the difference in the number of frames between the initiator’s query frame and the
`
`participant device’s frame at or near the rendering time of the selected query frame.
`
`Janevski, at col. 13:24-28. To synchronize the content, the participating device,
`
`based on the frame misregistration, searches for an appropriate frame to fast-forward
`
`or rewind toward. See generally id., at col. 13 l. 29–col. 15 l. 2.
`
`2.
`
`The Secondary References: Azevedo, Mills, Berthaud, and
`Eidson
`
`The Azevedo publication (Ex. 1010) is directed to convergence algorithms
`
`
`
`used in clock synchronization. Ex. 1010, at 1. Azevedo teaches smoothing of
`
`“correction terms” used in one algorithm. Ex. 1010, at 4.
`
`Mills (Ex. 1011) teaches smoothing clock offset values to “select the peer
`
`clock(s) used for synchronization [of computer clocks] and to maximize the
`
`accuracy and stability of the indications.” Ex. 1011, at 36.
`
`
`
`12
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`Berthaud (Ex. 1012) also addresses computer clock synchronization,
`
`specifically, correcting errors in the measurement of the offsets of computer clocks.
`
`Ex. 1012, at Abstract. Synchronization of the rendering of content is not addressed.
`
`Eidson, U.S. Patent No. 6,278,710 (Ex. 1013), is yet another disclosure related
`
`to synchronization of computer clocks. Ex. 1013. It teaches averaging the
`
`differences in time measurements for messages sent and received in computer
`
`networks, but it does not address the synchronization of the rendering of content.
`
`D. The Petition and the Institution Decision
`
`The Petition sought to initiate review on two grounds: (1) whether claims 1–
`
`3, 8, 11, and 17 of the ’252 Patent (“the Challenged Claims”) would have been
`
`unpatentable under § 103(a) as rendered obvious over the teachings of Janevski
`
`alone; and (2) whether Challenged Claims would have been unpatentable under §
`
`103(a) as rendered obvious over the teachings of Janevski, with the Secondary
`
`References (and other reference, Baumgartner). Paper 1, at 26.
`
`The Board instituted review on clams 1–3, 8, 11, and 17 of the ’252 Patent as
`
`unpatentable under 35 U.S.C. § 103(a) over Janevski and each one Azevedo, Mills,
`
`Berthaud, and Eidson. Implicit now files this Patent Owner’s Response.
`
`III. CLAIM CONSTRUCTION
`
`Implicit disagrees with Petitioner’s proposed constructions, as well as how the
`
`Petitioner has characterized Implicit’s positions in the District Court litigation. The
`
`bulk of those disputes, however, are for another day in the Implicit v. Sonos District
`
`
`
`13
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`Court litigation. While Implicit believes that its proposed constructions from the
`
`Implicit v. Sonos District Court litigation are correct and should apply here to assess
`
`patentability, Ex. 2010, Implicit will only address the explicit construction of claim
`
`terms as needed to address the issues raised with by the Petition regarding Janevski.
`
`IV. ARGUMENT
`
`A.
`
`Janevski is Not Prior Art
`
`Janevski is not prior art to the ’252 Patent. The Janevski reference has an
`
`effective filing date of December 11, 2001—only six days before the filing of the
`
`provisional application to which the Patent claims priority. Prior to December 11,
`
`2001, however, the inventors conceived of the inventions of the Challenged Claims,
`
`and those inventions were reduced to practice in time to remove Janevski as a prior
`
`art reference.
`
`For patents filed prior to the America Invents Act, a patentee can swear behind
`
`a reference if it can show (1) actual reduction to practice prior to the effective date
`
`of the prior art reference or (2) that it conceived of the inventions first and then,
`
`during the critical period, acted with reasonably continuous diligence to reduce the
`
`inventions to practice. Cooper v. Goldfarb, 154 F.3d 1321, 1327 (Fed. Cir. 1998).
`
`To establish actual reduction to practice, the inventor must show that he
`
`“constructed an embodiment or performed a process that met all the limitations of
`
`the claim, and that he determined that the invention would work for its intended
`
`purpose.” Slip Track Sys. v. Metal-Lite, Inc., 304 F.3d 1256, 1265 (Fed. Cir. 2002).
`
`
`
`14
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`Testing of the device is relevant to this inquiry, though it is not required. Id. at 1265,
`
`1267–68. To prove reduction to practice by inventor testimony, independent
`
`evidence must corroborate the testimony. Id. at 1265.
`
`A “rule of reason” analysis applies to determine if inventor testimony is
`
`adequately corroborated, which considers, as a whole, pertinent evidence to assess
`
`the credibility of the inventor testimony. NFC Tech., LLC v. Matal, 871 F.3d 1367,
`
`1372 (Fed. Cir. 2017). That analysis looks to the evidence as a whole, not
`
`individually, and may rely on circumstantial evidence. Id. “It is not necessary to
`
`produce an actual over-the-shoulder observer. Rather, sufficient circumstantial
`
`evidence of an independent nature can satisfy the corroboration requirement.
`
`Furthermore, an actual reduction to practice does not require corroboration for every
`
`factual issue contested by the parties.” Cooper, 154 F.3d at 1330 (Fed. Cir. 1998)
`
`(internal citations omitted).
`
`The evidence here shows that Janevski is not prior art because Implicit can
`
`swear behind it. That evidence includes the Declaration of Edward Balassanian (Ex.
`
`2001), the expert declaration of Atif Hashmi, Ph.D (Ex. 2080) and its accompanying
`
`claims charts (Ex. 2081 and 2082), and internal Implicit (then BeComm) documents,
`
`including source code. The expert testimony and documentary evidence adequately
`
`corroborates Mr. Balassanian’s testimony that, he and Mr. Bradley conceived of the
`
`inventions of the Challenged Claims prior to December 11, 2001 and timely reduced
`
`them to practice. E.g., Ex. 2001, at 6, 33, 42. As a result, Janevski is not prior art,
`
`
`
`15
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`and Implicit respectfully requests that the Board find each of the Challenged Claims
`
`patentable.
`
`1. How Strings Operated in 2001
`
`The synchronization functionality of the Challenged Claims resided in
`
`BeComm’s Strings operating system. Strings generally operated by executing
`
`“beads” using “rules.” Ex. 2001, at ¶¶ 39–40; Ex. 2080, at ¶¶ 20–24; Ex. 2021, at
`
`2–6; Ex 2022. A “bead” was a routine or set of routines that could manipulate
`
`computer information, Ex. 2001, at ¶ 39, such as decoding mp3 audio, Ex. 2076,
`
`displaying RGB video on a display device, Ex. 2050, or sending audio to a speaker
`
`for playback, Ex. 2051. The system worked by “stringing” together these “beads”
`
`to process data from a source to a destination. Ex. 2001, at ¶¶ 11–13; see, e.g., Ex.
`
`2002, at 6–9.; hence the name “Strings.” Ex. 2001, at ¶ 15.
`
`The “rules” configured how Strings would execute various beads. Written in
`XML format (which is like HTML), a rule (<RULE ... />) was a sequence of
`
`one or more steps that that execute when a specific set of constraints is met. Ex.
`2001, at ¶ 40; Ex. 2080, at ¶ 21–22. A rule had within it at least on route (<ROUTE
`... />), and each route contained at least one step (<STEP ... />) within the
`route. Ex. 2001, at ¶ 40; Ex. 2080, at ¶ 21–22. If a rule’s conditions were met (the
`<PREDICATE .../>), then Strings will execute the specific steps in the rule,
`
`which included executing the beads called in each step and setting variables in the
`
`namespace. Ex. 2001, at ¶ 40; Ex. 2080, at ¶ 21–22. The Strings engine would
`
`
`
`16
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`process these rules for a given application context and construct paths that strings
`
`together the beads to perform the processing for that application. Ex. 2001, at ¶ 40.
`
`A typical rule structure within Strings would have the following structure:
`
`Ex. 2080, at ¶ 21.
`
`By processing these rules to invoke beads, Strings could perform many
`
`
`
`functionalities. One example by 2001 was a media player in which Strings could
`
`take audio-video content from a camera and remotely output the video and audio
`
`separately on a remote device (or series of devices), Ex. 2001, at ¶¶ 16–17.
`
`
`
`17
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`
`Ex. 2002, at 9.
`
`In this example, the framer, MPEG encoder, RTP, UDP, and IP bead would
`
`
`
`take the audio video input from the camera, encode it, and format it for transmission
`
`over an IP network, such as the Internet. Ex. 2001, at ¶ 17. On the receiving end,
`
`Strings would process the transmission using the UDP and RTP beads and then parse
`
`the stream into its video and audio parts, each of which would be processed at the
`
`same time. Id.
`
`Another example usage of Strings during this time was to render audio content
`
`on the Intel Web Tablet stored on a user’s PC or content streamed from over the
`
`Internet. Ex. 2001, at ¶ 23. Running on the user’s PC and on the Tablet, Strings
`
`would retrieve the content from the PC, process the content and convert it into a
`
`format to playback on the Tablet, transmit the content to the Tablet, and then render
`
`the media on the Tablet. Id at ¶¶ 23–24.; see also Ex. 2006.
`
`
`
`18
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`2.
`Prior to December 11, 2001, the Inventors Conceived of the
`Challenged Claims and Reduced Them to Practice
`
`The genesis of what ultimately became the synchronization technology of the
`
`Challenged Claims began in late 2000 in connection with the “Juno” project for Intel,
`
`a project to build a Strings-enabled digital relay. Ex. 2001, at ¶¶ 26–32. Mr.
`
`Balassanian was part of the Juno project team as the President and CEO of BeComm,
`
`and Mr. Bradley was also involved in the project. Id. at ¶ 32; Ex. 2011, at 8.
`
`Intel required that the deliverable for Juno synchronize the audio playback
`
`across multiple receivers. At that time, however, “true synchronization [was] an
`
`unsolved computer science problem,” as both Intel and BeComm recognized. Ex.
`
`2001, at ¶ 29; Ex. 2009, at 15. BeComm would make a “best effort,” id., but
`
`synchronization would be “difficult at best,” Ex. 2011, at 37–38; see also Ex. 2001,
`
`at ¶ 29–30. Though Strings could distribute media at the same time to multiple
`
`devices for playback during this time, BeComm encountered the problem that the
`
`playback was out of sync. Id. at ¶¶ 26–28. Despite Intel putting the project on hold
`
`in in February 2001, Ex. 2001, at ¶ 30; Ex. 2012, BeComm continued to work on the
`
`synchronization problem.
`
`a.
`
`Conception
`
`In the ensuing months, Mr. Balassanian and Mr. Bradley conceived of the
`
`inventions set forth in the Challenged Claims and worked to reduce them to practice.
`
`Ex. 2001, at ¶¶ 33, 42–74 After Mr. Balassanian and Mr. Bradley conceived of the
`
`
`
`19
`
`

`

`IPR2018-00767
`Patent No. 8,942,252
`inventions, they communicated those inventions to BeComm’s internal engineering
`
`and development staff. Id. at ¶ 33. They primarily worked with Guy Carpenter, an
`
`Engineering Master at BeComm that was also staffed on the Juno project, to
`
`implement the inventions of the Challenged Claims. Id.
`
`The software implementing the inventions set forth in the Challenged Claims
`
`was complete and BeComm tested and demonstrated it prior to December 11, 2001.
`
`Ex. 2001, at ¶¶ 42–74. The system was operational for its intended purpose to
`
`synchronize the rendering and playback of video and audio content according to the
`
`inventions of the Challenged Claims. Id.
`
`BeComm source code and documents corroborate Mr. Balassanian’s
`
`testimony that the inventions were conceived and reduced to practice prior to
`December 11, 2001. Three beads—timesync, clocksync, and audiosync
`
`(for audio)—form the central core of BeComm’s embodiment of the Challenged
`
`Claims. Ex. 2001, at 34; Ex. 2008, at 38; Ex. 2037; Sonos Ex. 1008 in the IPR of
`the ’252 Patent. Initial versions of clocksync and timesync were checked into
`
`BeComm’s source code repository on