`
`I, Roman Chertov, declare and state as follows:
`
`1.
`
`I have been retained as an expert witness for the Inter Partes Review
`
`(“IPR”) of both U.S. Patent No. 7,391,791 (the “‘791 Patent”) (Ex.1001) and U.S.
`
`Patent No. 8,942,252 (the “‘252 Patent”), which have been initiated by Sonos, Inc.
`
`(“Sonos”) against Implicit, LLC (“Implicit”).
`
`2.
`
`I previously submitted two Declarations dated March 9, 2018
`
`(referred to herein as my “Opening Declarations”) in connection with Sonos’s
`
`Petitions for IPR of the ‘791 and ‘252 Patents.
`
`3.
`
`I understand that, on September 19, 2018, the Patent Trial and Appeal
`
`Board (or “the Board” for short) instituted IPRs of both the ‘791 Patent and the
`
`‘252 Patent.
`
`4.
`
`I further understand that, on December 18, 2019, Implicit filed its
`
`Patent Owner’s Responses (or “PORs” for short) in the IPRs of both the ‘791
`
`Patent and the ‘252 Patent along with a common set of Exhibits, which include
`
`source code produced by Implicit and an Expert Declaration of Atif Hashmi, Ph.D
`
`(Ex. 2080-2082) in which Dr. Hashmi expressed his opinion that the source code
`
`produced by Implicit practices the Challenged Claims of both the ‘791 Patent and
`
`the ‘252 Patent.
`
`5.
`
`I have now been asked to review the source code produced by Implicit
`
`and the Expert Declaration of Dr. Hashmi and then respond to Dr. Hashmi’s
`
`
`
`
`Page 1 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`opinion that the source code produced by Implicit practices the Challenged Claims
`
`of the ‘791 and ‘252 Patents. For the reasons set forth below, I disagree with Dr.
`
`Hashmi’s opinion that the source code produced by Implicit practices the
`
`Challenged Claims of the ‘791 and ‘252 Patents.
`
`I.
`
`BACKGROUND & QUALIFICATIONS
`
`6. My background and qualifications are set forth in my Opening
`
`Declarations.
`
`II. COMPENSATION
`
`7.
`
`As set forth in my Opening Declarations, I am being compensated for
`
`the time that I spend consulting on this IPR at a rate of $270 per hour, and my
`
`compensation does not depend on the outcome of these IPR proceedings.
`
`III. MATERIALS CONSIDERED
`
`8.
`
`In addition to the material identified in my Opening Declarations, I
`
`have now reviewed the source code and associated documentation (including Ex.
`
`2021) produced by Implicit, as well as the Expert Declaration of Dr. Hashmi (Ex.
`
`2080-2082).
`
`IV. LEGAL STANDARDS
`
`9.
`
`As I explained in my Opening Declarations, I am not an attorney and
`
`will not offer any opinions on the law. That said, I have been informed of various
`
`2
`
`
`Page 2 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`principles concerning invalidity of a patent, as well as other patent-related legal
`
`issues.
`
`V. LEVEL OF ORDINARY SKILL IN THE ART
`
`10. As set forth in my Opening Declarations, it is my opinion that, at the
`
`time of the alleged invention, a person having ordinary skill in the art
`
`(“PHOSITA”) in the technology area that is relevant to the ‘791 and ‘252 Patents
`
`would have had the equivalent of a four-year degree from an accredited institution
`
`(typically denoted as a B.S. degree) in computer science, computer engineering,
`
`electrical engineering, or an equivalent thereof, and approximately 2-4 years of
`
`professional experience in the fields of networked systems and networked-based
`
`applications, or an equivalent level of skill, knowledge, and experience.
`
`11.
`
`I applied this same level of ordinary skill in the art when formulating
`
`the opinions set forth herein.
`
`VI. CLAIM CONSTRUCTION
`
`12. As set forth in my Opening Declarations, I used the “broadest
`
`reasonable constructions” proposed in Sonos’s Petitions for IPR of the ‘791 and
`
`‘252 Patent, and to the extent that a claim construction was not provided for a
`
`particular claim term or phrase, I used the ordinary and customary meaning of the
`
`word(s), as would be understood by a PHOSITA in the context of the field of the
`
`invention, at the time of the invention, to construe such a claim term or phrase.
`
`3
`
`
`Page 3 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`13.
`
`I interpreted the claims in the same way when formulating my
`
`opinions set forth herein.
`
`VII. BRIEF INTRODUCTION TO DR. HASHMI’S OPINIONS
`
`14. According to Dr. Hashmi, the source code produced by Implicit
`
`(which Dr. Hashmi refers to as the “Implicit Source Code”) “specifies a distributed
`
`system” in which devices execute “a method for synchronizing rendering of
`
`content provided by a source” between a “mater rendering device” and a “slave
`
`rendering device.” See, e.g., Ex. 2081 at p. 1-4.
`
`15. Dr. Hashmi contends that the “master rendering device” (or the
`
`“master device” for short) is a particular rendering device in the “distributed
`
`system” specified by the Implicit Source Code that functions to receive media
`
`content from a source, render the received media content, and then encode and
`
`send the received media content along with corresponding “master rendering
`
`times” to one or more other rendering devices in the “distributed system.” See,
`
`e.g., Ex. 2080 at ¶¶ 35-36, 51-54; Ex. 2081 at p. 1-10.
`
`16.
`
`In turn, Dr. Hashmi contends that a “slave rendering device” (or a
`
`“slave device” for short) is a rendering device in the “distributed system” specified
`
`by the Implicit Source Code that functions to receive the encoded “master
`
`rendering times” and the encoded media content from the “master rendering
`
`device” and then adjust the received media content to “render synchronized
`
`4
`
`
`Page 4 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`[media] with the master device.” See, e.g., Ex. 2080 at ¶¶ 35-36, 55; Ex. 2081 at p.
`
`4-7, 10-12, 14-18.
`
`17.
`
`In my discussion of the Implicit Source code below, I have used the
`
`labels “master” and “slave” in the same way used by Dr. Hashmi in order to make
`
`it clear which device I am referring to when responding to Dr. Hashmi’s opinions.
`
`However, my use of these labels should not be taken to mean that I consider the
`
`devices specified in the Implicit Source Code to be “master” and “slave” rendering
`
`devices as those terms are used in the Challenged Claims of the ‘791 and ‘252
`
`Patents.
`
`18. Further, in my discussion of the Implicit Source Code below, I do not
`
`intend any of my descriptions of the functionality to suggest that the Implicit
`
`Source Code was actually able to be compiled or run either in 2001 or since that
`
`time. Rather, my discussion below is merely intended to articulate my
`
`understanding of how the Implicit Source Code was designed to function, without
`
`regard to whether that Implicit Source code was ever compiled or run.
`
`VIII. IMPLICIT SOURCE CODE DOES NOT PRACTICE ‘791 PATENT
`
`19.
`
`I respectfully disagree with Dr. Hashmi’s opinion that the Implicit
`
`Source Code practices the Challenged Claims of the ‘791 Patent for at least the
`
`following reasons, which apply to all Challenged Claims.
`
`5
`
`
`Page 5 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`A. The Implicit Source Code Fails to Practice the “Rendering Time”
`Limitations of the Challenged Claims of the ‘791 Patent
`
`
`20. Every Challenged Claim of the ‘791 Patent recites limitations directed
`
`to tracking and using “rendering times” of the designated “master” and “slave”
`
`rendering devices in order to synchronize the rendering of content at those
`
`rendering devices.
`
`21. For instance, Challenged Claims 1-3, 6-9, and 12 each require that (a)
`
`the “master device” has a “master rendering time,” (b) the “at least one slave
`
`device” has a “slave rendering time,” (c) the “master device” sends the “at least
`
`one slave device” “an indication of when the master device renders content
`
`corresponding to the master rendering time,” and (d) there is a determination of
`
`“whether a time domain differential exists between the master rendering time, the
`
`slave rendering time.” Ex. 1001 (‘791 Patent) at 8:25-53 (emphasis added).
`
`22. Further, Challenged Claims 16 and 19 each require that (a) “each
`
`device” participating in the synchronized rendering of content has a “rendering
`
`time,” including a “master device having a master rendering time” and “one or
`
`more slave devices having a slave rendering time,” (b) the “master device” sends
`
`the “one or more slaves” “a master device time corresponding to the master
`
`rendering time of the master device,” (c) there is a determination of “at least one
`
`time domain differential between the master rendering time and the slave
`
`rendering time between the master device and the one or more slave devices,” and
`
`6
`
`
`Page 6 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`(d) there is an adjustment of “the rendering of the content at the one or more slave
`
`devices to account for a difference in the slave rendering time and the master
`
`rendering time.” Id. at 9:45-10:6 (emphasis added).
`
`23. Further yet, Challenged Claims 23-25 each require that (a) “each
`
`device” participating in the synchronized rendering of content has a “rendering
`
`time,” including a “master device having a master rendering time” and “one or
`
`more slave devices having slave rendering time,” and (b) there is a calculation of
`
`“a time domain difference between the master rendering time of the master device
`
`and the slave rendering time of the slave device.” Id. at 10:37-52 (emphasis
`
`added).
`
`24. The construction of “rendering time” I have applied and used in
`
`formulating my opinions is “a time measure of the amount of content that has
`
`already been rendered by a given rendering device.” I understand that Implicit and
`
`Dr. Hashmi have not challenged this construction of “rendering time.”
`
`25. When applying this construction of “rendering time” to the Implicit
`
`Source Code, it is my opinion that the Implicit Source Code fails to practice any of
`
`the “rendering time” limitations of the Challenged Claims of the ‘791 Patent.
`
`26.
`
`Indeed, based on my review and evaluation of the Implicit Source
`
`Code, as well as Dr. Hashmi’s discussion of the Implicit Source Code in his Expert
`
`Declaration, I fail to see any evidence that the Implicit Source Code maintained “a
`
`7
`
`
`Page 7 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`time measure of the amount of content that has already been rendered by a given
`
`rendering device” at either a “master” device or a “slave” device.
`
`27. Further, because I fail to see any evidence that the Implicit Source
`
`Code maintained “a time measure of the amount of content that has already been
`
`rendered by a given rendering device” at a “master” device, I similarly fail to see
`
`any evidence that the Implicit Source Code practiced a function of sending a
`
`“master device time” or any other “indication” “corresponding to [a] master
`
`rendering time” from a “master” device to a “slave” device.
`
`28. Further yet, because I fail to see any evidence that the Implicit Source
`
`Code maintained “a time measure of the amount of content that has already been
`
`rendered by a given rendering device” at either a “master device” or a “slave
`
`device,” I similarly fail to see any evidence that the Implicit Source Code
`
`practiced a function of determining a “time domain differential” between a “master
`
`rendering time” of a “master device” and a “slave rendering time” of a “slave
`
`device” and then adjusting the rendering of content at the “slave device” to account
`
`for such a “time domain differential.”
`
`29.
`
`In the Claim Chart for the ‘791 Patent that is included as part of his
`
`Expert Declaration, Dr. Hashmi identifies certain aspects of the Implicit Source
`
`Code that allegedly practice the “rendering time” limitations of the Challenged
`
`Claims of the ‘791 Patent. However, I disagree that any of these aspects of the
`
`8
`
`
`Page 8 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`Implicit Source Code evidence that “a time measure of the amount of content that
`
`has already been rendered by a given rendering device” was maintained at either a
`
`“master” device or a “slave” device, or that such a “time measure” was otherwise
`
`used in the manner required by the Challenged Claims of the ‘791 Patent.
`
`30. For instance, in his Claim Chart for the ‘791 Patent, Dr. Hashmi
`
`contends that “the avidemux bead instantiates a master rendering clock
`IAudioClock associated with the audio content stream,” and that “[t]his master
`rendering clock IAudioClock generates a plurality of master rendering times
`that are indicative of the of statuses of the rendering the combined audio and video
`
`content stream by the master rendering device at different times.” Ex. 2081 at 2
`
`(emphasis added). I disagree with Dr. Hashmi’s contention here for several
`
`reasons.
`
`31. First, I disagree with Dr. Hashmi’s contention that IAudioClock is
`a “clock” that “generates” time values. To the contrary, the Implicit Source Code
`
`makes clear that IAudioClock is merely an interface structure that allows for
`modification of an instance of SAMPLECLOCK, which is itself a data structure that
`is periodically updated via the IAudioClock interface such that it contains a
`snapshot of the time value indicated by a “master” device’s system clock. See,
`
`e.g., Ex. 2086 at ln. 64-72. Hence, neither IAudioClock nor SAMPLECLOCK is
`
`9
`
`
`Page 9 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`a separate “clock” that “generates” time values. Various aspects of the Implicit
`
`Source Code confirm this. For instance:
`
`● The avidemux bead specifies that IAudioClock is an interface
`structure of type SOS_ISAMPLECLOCK, which is created from the
`SAMPLECLOCK_CLASS. See Ex. 2043 at ln. 105, 1009-1013; see also
`Ex. 1025 at ln. 252-258 (specifying that the SOS_ISAMPLECLOCK type
`implements an interface via function pointers). Further, the avidemux
`bead
`specifies
`that
`and
`SOS_MASTERCLOCK_NAME
`SOS_RENDERCLOCK_NAME variables at the “master” device point to
`the IAudioClock interface structure. See Ex. 2043 at ln. 447-457.
`● The sampleclock.c file implements a series of functions like
`SampleClock_FrequencySet and SampleClock_Update for
`the SAMPLECLOCK data structure. These functions get invoked via the
`SOS_ISAMPLECLOCK interface structure. See Ex. 2086 at ln. 551-611.
`● The speaker bead uses an ISampleClock interface structure of type
`SOS_ISAMPLECLOCK, and this ISampleClock interface structure is
`set via lookup of the SOS_RENDERCLOCK_NAME path attribute. See
`Ex. 2043 at ln. 253-257; Ex. 2051 at ln. 54. As a result of this function,
`the ISampleClock interface structure in the speaker bead will point
`to
`that
`the
`the same SAMPLECLOCK data structure structure
`IAudioClock points to in the avidemux bead.
`● The speaker bead specifies that when a “master” device first creates an
`interface
`to
`its
`audio
`output
`device,
`the
`SampleClock_FrequencySet function is called, which copies the
`then-current time value indicated by the “master” device’s system clock
`into the Time variable of the SAMPLECLOCK data structure using the
`following operation:
`sampleclock->Time = SOS_Clock_TickGet();
`See Ex. 2051 at ln. 406-438, Ex. 2086 at ln. 337-399.
`● The speaker bead further specifies that while a “master” device
`renders audio, the Time variable of the SAMPLECLOCK data structure is
`periodically updated with the then-current time value indicated by the
`
`10
`
`
`Page 10 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`same
`this
`using
`clock
`system
`device’s
`“master”
`SOS_Clock_TickGet() function, as demonstrated by the following:
`
` SOS_CLOCK_TICK
`now
`=
`SOS_Clock_TickGet();
` ...
` context->ISampleClock->Update(
` context->ISampleClock,
` now,
` sample
` );
`
`See, e.g., Ex. 2051 at ln. 484-506.
`32. Second, I disagree with Dr. Hashmi’s contention that the
`
`IAudioClock interface structure at a “master” device generates a “master
`rendering time” as the parties are construing that term for purposes of these IPR
`
`proceedings. As explained above, IAudioClock provides an interface to a
`SAMPLECLOCK data structure at the “master” device, and the Time variable of
`that SAMPLECLOCK data structure does not contain “rendering time.”
`33.
`Indeed, as noted above, the Time variable of a SAMPLECLOCK data
`structure at a “master” device is set using the SOS_Clock_TickGet()
`function, which returns the current time value indicated by the “master” device’s
`
`system clock, or in other words, the “master” device’s system time. See Ex. 2051
`
`at ln. 406-438, 484-506; Ex. 2086 at ln. 337-399.1 However, a “master” device’s
`
`
`1 I note that in the speaker bead, there is an alternative operation for determining
`the Time variable of a SAMPLECLOCK data structure at a “master” device when
`samplesQueued > samplesPlayed, which is:
`
`11
`
`
`Page 11 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`system time does not provide “a time measure of the amount of content that has
`
`already been rendered by [the] rendering device.” See, e.g., Ex. 2051 at ln. 406-
`
`438, Ex. 2086 at ln. 337-399.
`
`34. To the contrary, depending on the operating system of a rendering
`
`device, the system time returned by the SOS_Clock_TickGet() function
`would reflect the system clock’s measure of the amount of time that has passed
`
`since an arbitrary start date/time such as January 1, 1970 at 00:00:00 (for Unix) or
`
`the date/time when the device’s operating system started (for Windows2) – which
`
`bears no relationship to “the amount of content that has already been rendered by
`
`[the] rendering device.” Or put another way, a rendering device’s system time is
`
`measured from a start date/time that is entirely independent of the rendering
`
`device’s rendering of content, and as a result, the system time returned by the
`
`
`
`
`
`
`
`
`now += (samplesQueued - samplesPlayed) *
`SOS_MSPERSECOND / context->Format.Frequency;
`
`Based on my understanding of the samplesPlayed and samplesQueued
`variables, it is not clear to me that this alternative operation would ever be
`executed, but even if it were, the foregoing confirms that the Time variable of a
`SAMPLECLOCK data structure at a “master” device would be set to an adjusted
`version of the “master” device’s system time, which is not a “rendering time.” See
`Ex. 2051 at ln. 487-498.
`2 See https://docs.microsoft.com/en-us/windows/desktop/api/timeapi/nf-timeapi-
`timegettime.
`
`12
`
`
`Page 12 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`SOS_Clock_TickGet() function provides no indication of “the amount of
`content that has already been rendered by [the] rendering device.”
`
`35. Thus, contrary to Dr. Hashmi’s contention, the IAudioClock
`interface structure defined in the Implicit Source Code did not generate or
`
`otherwise provide an interface to a “master rendering time” as the parties are
`
`construing that term for purposes of these IPR proceedings.
`
`36.
`
`In his Claim Chart for the ‘791 Patent, Dr. Hashmi also contends that
`
`a “master” device “uses the clocksync bead to encode the master rendering
`times” that are sent to the “slave” devices. Ex. 2081 at p. 8-9, 11 (emphasis
`
`added). I disagree – the time value encoded by the clocksync bead is not a
`“master rendering time” as the parties have construed that term for purposes of this
`
`IPR, because it is not “a time measure of the amount of content that has already
`
`been rendered by [the] rendering device.” Rather, the Implicit Source Code makes
`
`clear that the time value encoded by the clocksync bead at a “master” device
`would have been an adjusted system time of the “master” device – which does not
`
`provide “a time measure of the amount of content that has already been rendered
`
`by [the] rendering device” for the same reasons discussed above.
`
`37. The portion of the clocksync bead that would have served to
`encode the time value at a “master” device – which the Implicit Source Code refers
`
`to as “master epoch” – is reproduced below:
`
`13
`
`
`Page 13 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`
`
`See, e.g., Ex. 2020 at ln. 280-294.
`
`38. As shown, the clocksync bead would have retrieved the “master
`epoch” by calling an EpochGet function and passing in a IMasterClock data
`structure at the “master” device, which points to the same SAMPLECLOCK data
`structure as the IAudioClock interface structure discussed above. See, e.g., Ex.
`2020 at ln. 280-294; Ex. 2043 at ln. 447-451; Ex. 2086 at ln. 475-545. The
`
`retrieved epoch would then have been converted to network byte order and saved
`in the message. See, e.g., Ex. 2020 at ln. 290.
`
`39. The EpochGet function is defined in the sampleclock.c file.
`When this EpochGet function is called by the the clocksync bead, the
`function first sets an epoch variable (which is of the type SOS_CLOCK_TICK)
`using the following operation:
`
`epoch = sampleclock->Time - delta,
`
`14
`
`
`Page 14 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`where sampleclock->Time is the Time variable of the SAMPLECLOCK data
`structure at the “master” device – which as discussed above contains a snapshot of
`
`the “master” device’s system time – and delta is an adjustment factor that is
`applied to that system time. See Ex. 2086 at ln. 475-545.
`
`40.
`
`In turn, the EpochGet function copies the value of the epoch
`variable into an Epoch variable that points to a variable in the clocksync bead
`(which is also of the type SOS_CLOCK_TICK). See Ex. 2086 at ln. 475-545. It is
`this Epoch variable that would then be encoded as the “master epoch” and sent by
`the “master” device to each “slave” device in the “distributed system” specified by
`
`the Implicit Source Code. See Ex. 2020 at ln. 280-294.
`
`41. The foregoing confirms that the “master epoch” to be encoded by the
`
`clocksync bead at a “master” device is an adjusted system time of the “master”
`device – which does not provide a “time measure of the amount of content that has
`
`already been rendered by [the] rendering device” for the same reasons discussed
`
`above.
`
`42. Thus, contrary to Dr. Hashmi’s contention, the clocksync bead did
`not encode a “master rendering time” as the parties are construing that term for
`
`purposes of these IPR proceedings.
`
`43. For similar reasons, I also disagree with Dr. Hashmi’s contention that
`
`a “slave” device uses the clocksync bead to “decode[] the master rendering
`
`15
`
`
`Page 15 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`times.” See Ex. 2081 at 14-16. Specifically, the time value that would have been
`
`decoded by the clocksync bead at a “slave” device is a “master epoch” that was
`encoded by the clocksync bead at a “master” device – which is an adjusted
`system time of the “master” device that does not provide a “time measure of the
`
`amount of content that has already been rendered by [the] rendering device.”
`
`44. Turning to “slave rendering time,” in his Claim Chart for the ‘791
`
`Patent, Dr. Hashmi contends that “each slave device runs a clocksync bead that
`maintains a rendering clock RenderClock that tracks the rendering time for the
`slave device,” See, e.g., Ex. 2081 at 5 (emphasis added). I disagree with this
`
`contention for several reasons.
`
`45. First, Dr. Hashmi’s statement that RenderClock is maintained by
`the clocksync bead at a “slave” device is not quite accurate. Technically, the
`clocksync bead uses IRenderClock. However, I note that IRenderClock
`is referred to as RenderClock in the audiosync bead and certain rule files.
`Thus, in order to maintain consistency with Dr. Hashmi’s terminology, I have used
`
`RenderClock when describing this interface structure even as used in the
`clocksync bead.
`46. Second, as with IAudioClock described above, RenderClock is
`merely an interface structure that allows for modification of an instance of
`
`SAMPLECLOCK, which is itself a data structure that is periodically updated via the
`
`16
`
`
`Page 16 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`RenderClock interface such that it contains a snapshot of the time value
`indicated by a “slave” device’s system clock. See, e.g., Ex. 2086 at ln. 64-72.
`
`Hence, neither RenderClock nor SAMPLECLOCK is a separate “clock” that
`“tracks” time values. Various aspects of the Implicit Source Code confirm this.
`
`For instance:
`
`● The syncaudio.rule file specifies that RenderClock at a “slave”
`device is created from the sampleclock class. See Ex. 2066 at ln. 14.
`● RenderClock is an interface structure of type SOS_ISAMPLECLOCK.
`See Ex. 2017 at ln. 87 (specifying that RenderClock is an interface
`structure of type SOS_ISAMPLECLOCK); Ex. 2020 at ln. 85 (specifying
`is
`an
`interface
`structure
`of
`type
`that IRenderClock
`SOS_ISAMPLECLOCK).
`● The sampleclock.c file implements a series of functions like
`SampleClock_FrequencySet and SampleClock_Update for
`the SAMPLECLOCK data structure. These functions get invoked via the
`SOS_ISAMPLECLOCK interface structure. See Ex. 2086 at ln. 551-611.
`● The speaker bead uses an ISampleClock interface structure of type
`SOS_ISAMPLECLOCK, and this ISampleClock interface structure is
`set via lookup of the SOS_RENDERCLOCK_NAME path attribute. See,
`e.g., Ex 2017 at ln. 358-364; Ex. 2051 at ln. 253-268. As a result of this
`function, the ISampleClock interface structure in the speaker bead
`will point to the same SAMPLECLOCK data structure structure that the
`RenderClock interface structure points to.
`● The speaker bead specifies that when a “slave” device first creates an
`interface
`to
`its
`audio
`output
`device,
`the
`SampleClock_FrequencySet function is called, which copies the
`“slave” device’s then-current system time value into the Time variable
`of the SAMPLECLOCK data structure using the following operation:
`sampleclock->Time = SOS_Clock_TickGet();
`
`17
`
`
`Page 17 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`See Ex. 2051 at ln. 406-438, Ex. 2086 at ln. 337-399.
`● The speaker bead further specifies that while a “slave” device renders
`audio, the Time variable of the SAMPLECLOCK data structure is
`periodically updated with the “slave” device’s then-current system time
`using this same SOS_Clock_TickGet() function, as demonstrated
`by the following:
`
` SOS_CLOCK_TICK
`SOS_Clock_TickGet();
`=
`now
` ...
` context->ISampleClock->Update(
` context->ISampleClock,
` now,
` sample
` );
`See, e.g., Ex. 2051 at ln. 484-506.
`47. Second, I disagree with Dr. Hashmi’s contention that the
`
`RenderClock interface structure at a “slave” device tracks a “slave rendering
`time” as the parties are construing that term for purposes of these IPR proceedings.
`
`As explained above, RenderClock provides an interface to a SAMPLECLOCK
`data structure at a “slave” device, and the Time variable of that SAMPLECLOCK
`data structure does not contain “rendering time.”
`
`48. Rather, the Time variable of this SAMPLECLOCK data structure at a
`“slave” device is set with the return of SOS_Clock_TickGet() function. That
`function returns the current system time of the “slave” device – which does not
`
`provide “a time measure of the amount of content that has already been rendered
`
`18
`
`
`Page 18 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`by [the] rendering device” for all of the same reasons discussed above. See Ex.
`
`2051 at ln. 406-438, 484-506; Ex. 2086 at ln. 337-399.
`
`49. Thus, contrary to Dr. Hashmi’s contention, the Renderclock
`interface structure defined in the Implicit Source Code did not track or otherwise
`
`provide an interface to a “slave rendering time” as the parties are construing that
`
`term for purposes of these IPR proceedings.
`
`50. Lastly, in his Claim Chart for the ‘791 Patent, Dr. Hashmi contends
`
`that a “slave” device of the “distributed system” specified in the Implicit Source
`
`Code “runs an audiosync bead that calculates, adjusts, and smoothens a
`rendering time differential between the master rendering device and the slave
`
`rendering devices.” Ex. 2081 at 17-18 (emphasis added); see also id. at 5, 15.
`
`Again, I disagree – the time values that the audiosync bead operates on are not
`“rendering times” as the parties are construing that term for purposes of these IPR
`
`proceedings, because those time values do not provide “a time measure of the
`
`amount of content that has already been rendered by a given rendering device.”
`
`51. The audiosync bead defines an AudioSync_Adjust function
`that updates an “early” variable using the following operation:
`
`SOS_INT32 early = (SOS_INT32)(MasterEpoch-RenderEpoch),
`where MasterEpoch and RenderEpoch are both variables of the type
`SOS_CLOCK_TICK. See, e.g., Ex. 2017 at ln. 464-473.
`
`19
`
`
`Page 19 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`52. Further, the audiosync bead specifies that the MasterEpoch and
`RenderEpoch variables used in this operation are set by the following portion of
`the audiosync bead (which appears in the AudioSync_MessageHandler
`function):
`
`
`
`Ex. 2017 at ln. 717-730.
`
`53. As shown, this portion of the audiosync bead sets the
`renderEpoch variable by calling the EpochGet function via the
`RenderClock interface structure at the “slave” device. In turn, the EpochGet
`function updates the renderEpoch variable with the result of the following
`operation:
`
`epoch = sampleclock->Time - delta,
`where sampleclock->Time is the Time variable of the SAMPLECLOCK data
`structure – which as discussed above contains a snapshot of the “slave” device’s
`
`20
`
`
`Page 20 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`system time – and delta is an adjustment factor that is applied to that system
`time. See Ex. 2086 at ln. 475-545.
`
`54. Similarly, this portion of the audiosync bead sets the
`masterEpoch variable by calling the EpochGet function via the
`MasterClock interface structure at the “slave” device, which is tied to the
`SAMPLECLOCK data structure that is found via the SOS_MASTERCLOCK_NAME.
`See, e.g., Ex. 2017 ln. 366-372. The Time variable of the SAMPLECLOCK data
`structure will have been updated by the clocksync bead with an offset-adjusted
`version of the “master epoch” received from the “master” device. See Ex. 2020 ln.
`
`458-480. In turn, the EpochGet function sets the masterEpoch variable using
`the following operation:
`
`epoch = sampleclock->Time - delta,
`where sampleclock->Time is the Time variable of the passed-in
`SAMPLECLOCK data structure – which contains an offset-adjusted version of the
`last “master epoch” received from the “master” device – and delta is an
`adjustment factor that is applied to that “master epoch.” See Ex. 2086 at ln. 475-
`
`545.
`
`55. The foregoing demonstrates that the renderEpoch variable used by
`the audiosync bead is an adjusted system time of the “slave” device and the
`masterEpoch variable used by the audiosync bead is an adjusted system time
`
`21
`
`
`Page 21 of 45
`
`SONOS EXHIBIT 1022
`IPR OF U.S. Pat. No. 8,942,252
`
`

`

`
`
`of the “master” device – neither of which provides “a time measure of the amount
`
`of content that has already been rendered by [the] rendering device” for the same
`
`reasons discussed above.
`
`56. Thus, contrary to Dr. Hashmi’s contention, the audiosync bead
`does not use “rendering times” as the parties are construing that term for purposes
`
`of these IPR proceedings.
`
`57. For at least the foregoing reasons, I therefore disagree with Dr.
`
`Hashmi’s opinion that the Implicit Source Code practices the “rendering time”
`
`limitations of the Challenged Claims of the ‘791 Patent.
`
`B.
`
`
`58.
`
`The Implicit Source Code Fails to Practice a Method for
`Synchronizing Rendering of Content at Designated “Master” and
`“Slave” Rendering Devices as Required by the ‘791 Patent
`
`I understand that the Challenged Claims of the ‘791 Patent require a
`
`method of synchronizing rendering of content at designated “master” and “slave”
`
`rendering devices in a network.
`
`59.
`
`In his Expert Declaration, Dr. Hashmi expresses his opinion that the
`
`Implicit Source Code implements certain “distributed system” configurations that
`
`synchronized the rendering of content at designated “master” and “slave”
`
`rendering devices in a network. See, e.g., Ex. 2080 at ¶¶ 31-36; see also Ex. 2081
`
`at 2, 4, 6-7, 10-11, 14-15, 18. I disagree.