IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Inventors: Harold Edward Price
`
`Group Art Unit: 3992
`
`Application No. 90/014,833
`Filed: August 25, 2021
`Title: STREAMING MEDIA
`DELIVERY SYSTEM
`
`Examiner: WASSUM, Luke S.
`Confirmation No. 1250
`Patent No. 8,327,011
`
`MAIL STOP APPEAL BRIEF
`Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`REPLY BRIEF
`
`Appellant submits this Reply Brief in response to the Examiner's
`
`Answer dated March 15, 2023 (the "Answer").
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0001
`
`

`

`TABLE OF CONTENTS
`
`I. ARGUMENT .......................................................................................... 1
`A. GROUND 1 -ASSERTED ANTICIPATION OF CLAIMS 1 AND 4
`BY SHTEYN .............................................................................................. l
`1. MLl-2: ... each identified by a serial number. ............................... 1
`2. MLl-1: ... maintain a record of the serial number of the last media
`data element that has been received and stored in the player buffer ...... 7
`3. Claim 4, ML4-l: ... wherein the instructions ... further causes the
`media player to receive the predetermined number of media data
`elements at a rate more rapid than the rate at which the media data
`elements are to be played out by the media player. ................................ 9
`B. GROUND 2A - ASSERTED OBVIOUSNESS OF CLAIM 4 OVER
`SHTEYN + CARMEL .............................................................................. 13
`1. Carmel fails to disclose ML4- l. .................................................... 13
`2. The Answer fails to identify a sufficient motivation for a POSITA
`to combine Carmel and Shteyn ............................................................. 17
`C. GROUND 2B - ASSERTED OBVIOUSNESS OF CLAIM 4 OVER
`SHTEYN + GLASER ............................................................................... 21
`1. Glaser fails to disclose ML4- l ...................................................... 21
`D. GROUND 3A - ASSERTED ANTICIPATION OF CLAIMS 1 AND 4
`BY HILL ................................................................................................... 22
`1. ML 1-2: ... transmit to the media source a request to send one or
`more media data elements, each identified by a serial number ............ 22
`2. MLl-1: ... maintain a record of the serial number of the last media
`data element that has been received ...................................................... 23
`3. Claim 4, ML4-l: ... wherein the instructions ... further causes the
`media player to receive the predetermined number of media data
`elements at a rate more rapid than the rate at which the media data
`elements are to be played out by the media player. .............................. 24
`E. GROUND 3B - ASSERTED OBVIOUSNESS OF CLAIM 4 OVER
`HILL + CARMEL .................................................................................... 25
`1. Carmel fails to disclose ML4- l. .................................................... 25
`F. GROUND 3C - ASSERTED OBVIOUSNESS OF CLAIM 4 OVER
`HILL + GLASER ...................................................................................... 26
`
`..
`- 11 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0002
`
`

`

`1. Glaser fails to disclose ML4- l ...................................................... 26
`G. GROUND 4 - ASSERTED OBVIOUSNESS OF CLAIMS 1 AND 4
`OVER SHTEYN + HILL ......................................................................... 27
`1. Hill fails to disclose ML4- l .......................................................... 28
`2. Lack of rationale to combine ........................................................ 28
`H. GROUND 6A - ASSERTED ANTICIPATION OF CLAIMS 1 AND 4
`BY CARMEL ........................................................................................... 28
`1. ML 1-3: ... repeat transmitting the requests to the media source for
`sequential media data elements so as to maintain the pre-determined
`number of media data elements in the player buffer until the last media
`data element comprising the program has been received ..................... 28
`2. Claim 4, ML4-l: ... wherein the instructions ... further causes the
`media player to receive the predetermined number of media data
`elements at a rate more rapid than the rate at which the media data
`elements are to be played out by the media player. .............................. 33
`I. GROUND 6B - ASSERTED OBVIOUSNESS OF CLAIMS 1 AND 4
`OVER CARMEL + HILL ........................................................................ 34
`J. GROUND 9A - ASSERTED ANTICIPATION OF CLAIM 1 BY
`IMAI ......................................................................................................... 35
`1. ML 1-4: ... receiving an audio or video program, the program
`comprising media data elements ........................................................... 35
`2. MLl-1: ... maintain a record of the serial number of the last media
`data element that has been received ...................................................... 36
`3. ML 1-3: ... repeat transmitting/maintain the player buffer ........... 36
`K. GROUND 9B - ASSERTED OBVIOUSNESS OF CLAIM 4 OVER
`IMAI+ CARMEL .................................................................................... 37
`1. Carmel fails to disclose ML4- l. .................................................... 3 7
`L. GROUND 9C - ASSERTED OBVIOUSNESS OF CLAIM 4 OVER
`IMAI+ GLASER ...................................................................................... 38
`II. CONCLUSION ..................................................................................... 38
`
`- 111 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0003
`
`

`

`I. ARGUMENT
`
`Abbreviations for certain missing limitations
`
`The abbreviations and reference labels previously used in Appellant's
`
`Appeal Brief are used again in the following arguments herein.
`
`A. GROUND 1 - ASSERTED ANTICIPATION OF CLAIMS 1 AND
`
`4BY SHTEYN
`
`1. MLl-2: ... each identified by a serial number
`
`Shteyn does not disclose limitation MLl-2: "transmit to the media source a
`
`request to send one or more media data elements, each identified by a serial
`
`number." As Appellant argued in its Appeal Brief, there is a substantial and
`
`patentably distinct difference between requests formatted as "give me the next
`
`element," as Shteyn discloses, versus requests formatted as "give me element X,"
`
`where "X" is the serial number of the desired element, as recited in MLl-2.
`
`The Examiner's first argument, pressing a "broad" interpretation of the term
`
`"serial number," is to no avail. The term should be taken as a serial identifier, and
`
`Appellant has in no way sought to limit its scope to sequential cardinal numbers or
`
`the like. But such a serial identifier must still function to unambiguously identify
`
`the individual elements arranged in a series. The Examiner's clarification of "serial
`
`number," while in itself accurate, does not change the analysis of any of the
`
`references here. So long as "serial number" is understood as at least requiring
`
`- I -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0004
`
`

`

`unambiguous identification of respective elements constituting a series, Shteyn
`
`does not apply.
`
`The Answer reads Shteyn through the lens of the disclosure of the '011
`
`patent and thus incorrectly concludes that in Shteyn segment location information
`
`"would necessarily be included in a request for download of said file segment,"
`
`arguing that a server location where an element is resident "is analogous to the
`
`claimed 'serial number."' Answer at 10. In doing so, the Answer is raising an
`
`inherency argument without any underlying factual support and contrary to the
`
`plain reading of Shteyn.
`
`Inherency, however, is a question of fact that must meet a high standard for
`
`showing that a limitation is necessarily present in the prior art. Without underlying
`
`factual support, any inherency argument must fail. PAR Pharm., Inc. v. TWI
`
`Pharm., Inc., 773 F.3d 1186, 1194 (Fed. Cir. 2014) ("inherent teaching of a prior
`
`art reference is a question of fact."); id. at 1195-96 (establishing inherency requires
`
`"meet[ing] a high standard" to establish that a "limitation at issue necessarily must
`
`be present" in the prior art). The Answer does not meet this high burden. A
`
`"location" may be specific to each item (one location for each item). Or, it may
`
`specify a location from which a plurality of items may be obtained, or where they
`
`are stored. Shteyn only discloses the latter, which does not meet the limitation.
`
`- 2 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0005
`
`

`

`If what is being delivered is a sequence of items, the server can track the
`
`ones that have been delivered, and the client, knowing the location to make the
`
`request, need not specify a serial identifier in its request.
`
`The first observation in the Answer is that "Shteyn discloses media [content]
`
`files that are split into multiple parts [segments]." Answer at 6 ( alterations in
`
`original) ( citing Shteyn at I :65-66). It is true that Shteyn discloses that "the content
`
`file is split into multiple parts. Each part or segment requires a relatively short
`
`download time" (Shteyn, I :65-66), but nothing in this teaches that each segment
`
`has a corresponding serial number that is used in requesting them, as required of
`
`MLl-2.
`
`Figure 2 of Shteyn depicts an XML control file including "<partl>"
`
`metadata and "<part I_ alt>" metadata. According to Shteyn:
`
`"part I" is in a preferred format and described the length of the part,
`e.g., in bytes, the format, the minimum bandwidth required for a
`connection, and the location on the Internet. An alternative first part is
`labeled "partl alt" having a different length, different format, different
`minimum bandwidth requirement, and a different location.
`
`Shteyn, 3 :48-53.
`
`The Answer argues that, within an XML file depicted in Figure 2 of Shteyn,
`
`"either the segment label (e.g., partl, partl_alt) or the location could serve to
`
`identify a specific segment, and so would satisfy the preamble limitation that each
`
`of the media elements is associated with a serial number." Answer at 7 (emphasis
`
`- 3 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0006
`
`

`

`in original). However, there is no disclosure in Shteyn that any of the <part I> or
`
`<part I_ alt> metadata in the XML file is actually used in a request for a specific
`
`segment, as required by MLl-2 (and certainly not that the server recognizes them
`
`as "partl", "partl_alt", etc.) The Answer also alleges that, "[a]t a minimum, the
`
`disclosed 'location' field would satisfy this claim limitation." Answer at 8
`
`( emphasis in original omitted). This merely assumes that the "location" shown is a
`
`unique location, with separate unique "locations" provided, one location for each
`
`serial item. This is not shown. A disclosure that leaves open alternate different
`
`embodiments is insufficient as a matter of law to render one of them inherent.
`
`The <location> information in the XML file refers to a server location, such
`
`as ftp://137.27 .52.87 (Shteyn, Figure 2), which identifies the address of an ftp
`
`server, and does not represent a serial identifier of a data element. There is no
`
`disclosure in Figure 2 of Shteyn or otherwise in the reference, of control file
`
`metadata reflecting any kind of serial identifier for an individual segment.
`
`The XML tag partl as shown only shows a location from which the parts
`
`may be obtained, a content size for the parts (1024 bytes), a format, and a
`
`min_ bandwidth. The label "part I" is only internal schema for the XML file, not an
`
`identifier that identifies a specific file segment on the server. All that Shteyn
`
`discloses is that after the first part (e.g., of I 024 bytes), the client requests the
`
`"next" part ( of the same size).
`
`- 4 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0007
`
`

`

`It very well may be that "part I" and "part I_ alt" are merely representative of
`
`the control file's contents, and that there might be a "part2" (and a "part2_alt,"),
`
`etc., in an actual XML file in accordance with Shteyn. However, a POSITA would
`
`expect that the fields of these additional parts would track the same field layout as
`
`illustrated for the parts that are shown, i.e., <length>, <format>, <location>, and
`
`<min_bandwidth>, as represented for partl and partl_alt.
`
`Note that Figure 2 of Shteyn does not show any individual identifier in
`
`"<partl>" or "<partl_alt>" for a segment that would be requested from the
`
`"<location>" provided. On the reasonable expectation that all the other "locations"
`
`for the respective parts would be of the same type as the ones illustrated, the
`
`"location" for each of those parts will just be an address where the part data is
`
`available, i.e., no different for part2 ... partn than as shown for part I.
`
`Rather than provide citations to where Shteyn discloses requesting
`
`individual segments by serial number, the Answer instead falls back asserting
`
`inherency:
`
`A request to download a file (i.e., segment, media data element) must
`necessarily include the location on the Internet from which the file is
`to be retrieved. Therefore, Shteyn discloses the claimed request to
`send one or more media data elements, each identified by a serial
`number, wherein the claimed 'serial number' is analogous to the
`disclosed 'location'."
`
`Answer at 8. As noted above, the "location" (such as the cited IP address expressly
`
`shown in Shteyn) may very simply identify a server or other facility from which a
`
`- 5 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0008
`
`

`

`plurality of media data elements ("first and subsequent") may be obtained or are
`
`stored. It does not unambiguously identify any of the individual segments stored at
`
`the specified location.
`
`The Answer at 9-10 points to excerpts from Shteyn to argue that control
`
`information in Shteyn' s XML file includes not just the location (i.e., server) of the
`
`segments but also URLs for these segments, and repeats the inherency argument,
`
`stating that "the disclosed 'location' identifies a single file segment, and would
`
`necessarily be included in a request for download of said file segment (i.e., it is
`
`analogous to the claimed 'serial number')." Answer at 10. But the Answer
`
`identifies no disclosure that the location contains a single file segment. The next
`
`"location" may be exactly the same location as the first, but in any case is not
`
`shown. Taken at face value, this argument would imply provisioning a separate ftp
`
`IP address for each 1024-byte segment in an audio recording. Nothing like that is
`
`disclosed, of course, and the Answer cites to nothing to factually support the
`
`inherency argument that such a URL "would necessarily be included in a request."
`
`Shteyn's actual disclosures are to the contrary, stating that the client is only asking
`
`for the "next" element from the specified location, leaving it to the server to
`
`determine what is "next."
`
`The only written description in Shteyn that actually concerns such requests
`
`from the client to the server is that "[i]n step 110, the next file segment is
`
`- 6 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0009
`
`

`

`downloaded." Shteyn, 3:14; see also id., Figure 1, element 110. No usage ofURLs
`
`or other identifiers is disclosed, other than "next," which does not identify a
`
`particular segment and thus falls short of being a serial number, under any
`
`reasonable interpretation. Shteyn is silent as to the format of the request and there
`
`is no evidence of record that its usage of an identifier of a specific segment from
`
`the series available is inherent.
`
`2. MLl-1: ... maintain a record of the serial number of the last
`
`media data element that has been received and stored in the player
`
`buffer
`
`This limitation concerns what the player receives as opposed to what it
`
`requests. The Answer again relies on inherency to argue that Shteyn discloses
`
`MLl-1, "maintain a record of the serial number of the last media data element that
`
`has been received and stored in the player buffer." But there is nothing in the
`
`disclosure of Shteyn that teaches or suggests that this feature must necessarily be
`
`present, and the Answer cites to no other support for this proposition.
`
`The Answer argues that:
`
`The system progresses sequentially through the XML content file
`downloading file segment after file segment ( e.g., partl, part2 ...
`part(x)). In doing so, the system necessarily maintains information
`with respect to the last downloaded segment, in order to know which
`segment is the 'next' one (e.g., part(x+ 1)) to be downloaded.
`
`Answer at 12 ( emphasis added).
`
`- 7 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0010
`
`

`

`A first problem with this assertion is that it assumes that "the system" that is
`
`maintaining state as to the transmission is the client, and not the server. This is not
`
`necessarily the case, but the Answer's approach assumes its conclusion. That
`
`conclusion, that the client system is performing this function, is not supported by
`
`the actual disclosure of Shteyn.
`
`The Answer's assertion that the client "necessarily" maintains information
`
`with respect to the last downloaded segment ... in order to know which segment is
`
`'next"' assumes that some other facility (e.g., the server) is not doing so. The
`
`Answer does not cite anything to rule out the latter. The asserted "necessary"
`
`character of the matter results only from assuming the other possibilities away.
`
`The Answer also cites to nothing in Shteyn to support the assertion that the
`
`information the client stores with respect to a downloaded segment includes a
`
`serial number that was used in the original request for that segment, which is
`
`required of MLl-1. There is no disclosure of such a request serial number to begin
`
`with, no indication that the same is stored, and no basis to say that the system of
`
`Shteyn has any need for it. The stored XML list of Figure 2 in Shteyn shows what
`
`the client may request. It does not address maintaining a record of what has been
`
`received. As Appellant has previously argued, a list of all elements that potentially
`
`can be received is not the same as a running record of what has actually been
`
`received.
`
`- 8 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0011
`
`

`

`Finally, the Answer seeks to buttress the underlying inherency argument by
`
`alleging that "[w]ere [it] not the case [that Shteyn's client maintains a record of the
`
`serial number of the last segment received], then there would be no way for the
`
`system to know which file segment in the XML file is the 'next' segment to be
`
`downloaded and buffered." Answer at 12-13. Again, the Answer ambiguously uses
`
`the words "the system." There is a system disclosed by Shteyn that performs this
`
`function, but it is the server. It is the server in Shteyn that maintains the record of
`
`what was last sent and thus knows what segment is "next." The inherency
`
`arguments proffered in the Answer must thus fail.
`
`For each of the parts, the client knows the location from which to get the
`
`next segment, so all it needs to do is request "next" from that location, as Shteyn in
`
`fact says. Respectfully, it does not at all follow that "the system necessarily
`
`maintains information with respect to the last downloaded segment, in order to
`
`know which segment is the 'next' one ... to be downloaded."
`
`MLl-1 is thus not inherent to the disclosure of Shteyn.
`
`Based on the points addressed so far, Shteyn does not anticipate claim 1.
`
`3.
`
`Claim 4, ML4-1: ... wherein the instructions ... further
`
`causes the media player to receive the predetermined number of
`
`- 9 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0012
`
`

`

`media data elements at a rate more rapid than the rate at which the
`
`media data elements are to be played out by the media player
`
`Turning to the asserted anticipation of claim 4 by Shteyn, the Answer argues
`
`that:
`
`At best, claim 4 requires that the software on the client media player is
`capable of receiving data at a rate exceeding the playback rate, in
`those cases where the transmission rate is sufficiently high to permit
`such reception speed. It would not be possible to write software that
`receives data at a rate greater than the rate at which it is transmitted,
`and the claims are silent with respect to the transmission rate of the
`media data elements.
`
`Answer at 15.
`
`Even under that approach, the Answer must show that disclosed
`
`corresponding player software of Shteyn in fact has the stated capability. The
`
`Answer reasons that the player software in Shteyn must have this capability
`
`because:
`
`• The Background and Summary sections of Shteyn (1:50-2:1) teach to
`
`address the latency problem of downloading an entire file by splitting
`
`the file into multiple parts, each requiring a "relatively" short
`
`download time.
`
`• The <min_ bandwidth> tag in the control file, indicating the minimum
`
`bandwidth necessary for the encoding.
`
`- 10 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0013
`
`

`

`• The disclosure at 4:20-23 that "the client application could select a
`
`next segment in a different format for the same content to adapt to
`
`changing circumstances, e.g., lower bandwidth due to network
`
`congestion."
`
`Respectfully, this falls short of disclosing ML4-1. It is certainly not an
`
`express disclosure. Nor is it inherent, because it requires only matching, not
`
`exceeding, the minimum bandwidth.
`
`Shteyn discloses that program segments may be received in "relatively"
`
`short download times, as compared to downloading the entire content file for the
`
`program. See Shteyn, 1:42-66. Nevertheless, Shteyn does not teach to send (or
`
`receive) each segment of the content file, or even the recited "predetermined
`
`number" of elements, more rapidly than the playback rate. The word "relative" is
`
`far short of the required disclosure.
`
`Moreover, the Answer's arguments fail to address exactly what must be
`
`received faster than the playback rate.
`
`While these disclosures may be taken as suggesting, or perhaps even
`
`implying, a minimum bandwidth (e.g., 10,000 in one of Shteyn's examples)
`
`required for optimal throughput of the stream, the limitation in question is drawn
`
`to a "predetermined number of elements," and the antecedent of that number is the
`
`"predetermined number" requested at the outset per parent claim 1, which the
`
`- 11 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0014
`
`

`

`player thus starts with and acts to maintain in its memory throughout transmission.
`
`If there are interruptions ( and on the internet there will be), the predetermined
`
`number of elements thus maintained on the player side will be sufficient to protect
`
`the player from a worst-case total interruption up to the duration of the
`
`predetermined number of elements. See '011 patent, 11:64-12:3.
`
`Given the likelihood of unpredictable interruptions on the internet, it is more
`
`difficult to assure that each of a succession of shorter segments will be delivered
`
`within a specified time, as compared to when throughput can be averaged over a
`
`longer interval, and the average relied upon. See 'O 11 patent, 5 :31-39. Shteyn at
`
`most implies keeping up the average minimum specified bandwidth over an open(cid:173)
`
`ended period of transmission. Shteyn notes that that the transmission may
`
`nevertheless bog down (and thus clearly not meet the criterion), prompting a shift
`
`to a lower data quality, and again matching the available bandwidth. But this does
`
`not mean that at all times during transmission segments of the size of the
`
`predetermined number of elements will or could be received faster than the
`
`playback rate. Over time, the throughput will tend to match the playback rate, but
`
`there is no teaching from which to conclude that the player's buffer contents (the
`
`predetermined number of elements) can be refilled (from scratch) whenever this
`
`might be needed, faster than the playback rate.
`
`- 12 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0015
`
`

`

`Because of the foregoing deficiencies ( and the failure of Shteyn to meet the
`
`specified limitations of parent claim 1 ), Shteyn cannot be found to anticipate claim
`
`4.
`
`B.
`
`GROUND 2A - ASSERTED OBVIOUSNESS OF CLAIM 4
`
`OVER SHTEYN + CARMEL
`
`Ground 2A is directed only at claim 4. It proceeds on the premise that even
`
`if Shteyn does not disclose ML4-1, Carmel allegedly does, and further that it
`
`would have been obvious to have modified Shteyn in accordance with Carmel's
`
`( alleged) teaching of ML4-1.
`
`1.
`
`Carmel fails to disclose ML4-1
`
`The Answer argues that, as Carmel teaches to expect a connection in which
`
`the "data rate will generally be equal to or faster" than the playback rate, the player
`
`software must therefore be capable of receiving those portions that were sent faster
`
`than the playback rate, including individual elements sent at that rate, per the
`
`Federal Circuit's decision. See answer at 17-18.
`
`The Answer fails to address that there is more to this limitation, in particular,
`
`receiving "the predetermined number" of elements at the specified rate. Claim 4 in
`
`its entirety recites:
`
`4. The media player of claim 1, wherein the instructions for causing
`the media player to request from the media source a predetermined
`number of media data elements further causes the media player to
`receive the predetermined number of media data elements at a rate
`
`- 13 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0016
`
`

`

`more rapid than the rate at which the media data elements are to be
`played out by the media player.
`
`'011 patent, claim 1 (emphasis added). Carmel cannot meet claim 4 for at least the
`
`reason that the predicate, which references the media player's "request from the
`
`media source a predetermined number of media data elements" ( and ultimately has
`
`a predicate in claim 1) cannot be found in Carmel.
`
`All that is of record in this regard is the initial office action in this
`
`proceeding, which points to disclosures that are simply not in Carmel, apparently
`
`cut and pasted in error from a description of a different reference (Feig). See Office
`
`Action dated March 4, 2022, at 63-64. The action failed to point to any
`
`corresponding disclosure of Carmel, and there is no such disclosure.
`
`Carmel discloses requests that specify one element and are responded to
`
`with an open-ended stream. For example:
`
`• "When one of computers 30 connects to server 36 and begins to
`
`download the data stream, it first reads the index file in order to
`
`identify at what point in stream 40 to begin .... " Carmel, 8: 1-4
`
`( emphasis added).
`
`• "In a preferred embodiment, downloading the sequence includes
`
`selecting a file in the sequence earlier than the file whose index is
`
`contained in the index file and downloading at least a portion of the
`
`- 14 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0017
`
`

`

`sequence of files beginning with the selected file." Carmel, 4:7-11
`
`( emphasis added).
`
`• "When one of computers 30 reads index file 50 and begins to
`
`download stream 40, indicator 58 preferably marks the most recent
`
`slice, as shown in FIG. 3C." Carmel, 8:32-34 (emphasis added).
`
`• "Responsive to a user input, client 30 selects an appropriate starting
`
`slice and begins to download and decode (decompress) files 42, 44,
`
`46, etc." Carmel, 10:44-47 (emphasis added).
`
`• "After reading header 43 and, preferably, making an initial assessment
`
`of the link bandwidth, the client selects one of the available quality
`
`levels in the stream. Responsive to the selection, server 36 begins to
`
`transmit data slices at the chosen quality level. The slices are
`
`received, decoded and output by the client." Carmel, 11 :2-8 ( emphasis
`
`added).
`
`The only disclosure is that the server "begins" to send a stream of elements
`
`from a designated starting slice, and that the requests that trigger such sending
`
`involve only sending to the server an identification of the starting slice. The
`
`number of elements sent responsive to that one request is open-ended. The
`
`disclosure does not say how many elements follow in the stream initiated in this
`
`manner. This does not reflect a request for "a predetermined number" of media
`
`- 15 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0018
`
`

`

`data elements, which is the predicate for ML4-1' s recitation of "causes the media
`
`player to receive the predetermined number of media data elements at a rate more
`
`rapid than the rate at which the media data elements are to be played out by the
`
`media player."
`
`If the Answer wished to maintain that the words "predetermined number" in
`
`claim 4 means only "one" element, it would have to show that Carmel makes a
`
`new request every time it plays an element out of its store of elements. There is no
`
`disclosure like this in Carmel. Even if one were to infer a repetition of HTTP
`
`requests based on the "loops" generally pictured in Carmel, Figures 6A and 6B
`
`reflect that the requests trigger a response that includes an unspecified plurality of
`
`slices, not a "predetermined number" as claimed.
`
`In Carmel, there is thus no disclosure of a request for a predetermined
`
`number of media data elements, and no disclosure of instructions that cause the
`
`player to receive such "predetermined number" of media data elements, as no such
`
`predetermined number is a part of Carmel. For at least this reason, ML4-1 cannot
`
`be met by Carmel.
`
`Furthermore, ML4-1 is worded in terms of receiving the predetermined
`
`number of elements, at the specified rate. Putting aside the fact that Carmel doesn't
`
`even request or receive a "predetermined number" of elements, Carmel also does
`
`- 16 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0019
`
`

`

`not disclose that such a number of elements are caused to be received at the
`
`specified rate.
`
`The Answer addressed receiving individual elements. See Answer at 16.
`
`However, it failed to address receiving a "predetermined number" of elements at
`
`the specified rate. There is no disclosure that the player software of Carmel is
`
`capable of "receiving" the "predetermined number" of elements at the rate
`
`specified, or indeed any plurality of elements of any specified length ( other than
`
`one), at faster than the playback rate. Yet doing so is material to achieving the
`
`objects of the claimed invention, because the ability to maintain the predetermined
`
`number of elements in the player memory, even if the predetermined number must
`
`be reestablished (in the worst case) from a buffer that has been all but fully
`
`depleted by an interruption, is what allows the system to achieve the greater
`
`freedom from interruptions that the 'O 11 patent addresses.
`
`For at least these reasons, Carmel does not teach ML4-1.
`
`2.
`
`The Answer fails to identify a sufficient motivation for a
`
`POSITA to combine Carmel and Shteyn
`
`The Answer improperly characterizes both Shteyn and Carmel as "pull"
`
`architectures. Shteyn is a "pull" insofar as to teach for the client to "pull" the
`
`"next" element.
`
`- 17 -
`
`Petitioner's Exhibit 1109
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0020
`
`

`

`But Carmel is in no way a "pull." Other than the fact that a user action
`
`initially starts ( or optionally, re-starts) the streaming process, what Carmel
`
`discloses is a "push." The client requests the stream starting from the latest
`
`available slice, or optionally from an earlier user-selected starting point.
`
`Responsive to such a request, the server in Carmel pushes slices to the client, as
`
`Appellant discussed at length in the Appeal Brief. In this context, the Answer
`
`presents no cognizable motivation for a POSIT A to combine "push" teachings of
`
`Carmel, in which the server sends slices to the client without respective client-side
`
`requests, into Shteyn, in which the client "pulls" the "next" element from the
`
`server.
`
`The Answer arg