US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Contention
`WAG has asserted three patents against YouTube LLC and/or affiliated entities such
`as Google LLC (“YouTube”), which concern streaming media over the Internet,
`conducted between a user (client) system, which requests and plays the media, and
`a server to which the client system connects over the Internet, which provides the
`requested media. WAG’s ’824 patent (the subject of the within contentions)
`concerns methods, apparatus, and computer program products on the server side of
`this interaction, for prerecorded media. WAG’s ’594 patent concerns methods,
`apparatus, and computer program products on the client side of the above-
`described interaction. WAG’s ’636 patent corresponds to the ’824 patent in certain
`respects, but concerns live media (e.g., live performances) created
`contemporaneously with its streaming. Because the subject matter of these patents
`overlap, WAG’s infringement contentions with regard to the ’594 and ’636 patents
`are each incorporated herein by reference.
`
`YouTube directs and controls the activity of streaming digitally encoded media it
`provides over the Internet through the site youtube.com (also accessible as
`www.youtube.com) (the “YouTube Web Site”) from servers owned and/or the
`operations of which are controlled by YouTube, including servers in the U.S. and in
`the Western District of Texas (“YouTube’s Servers”).
`
`These contentions relate to every streaming video program accessible from or
`through the YouTube Site for the period from the 2017 issuance dates of the patents
`addressed in these contentions, through the date of expiration (March 28, 2021).
`They further relate to videos streamed from YouTube’s Servers (e.g.,
`googlevideo.com, tv.youtube.com) to embedded “YouTube” devices and apps. Also
`included in these contentions is streaming audio distribution from
`music.youtube.com (formerly Google Play Music), as well as the YouTube TV
`subscription service (available for distribution through tv.youtube.com). The
`foregoing services are addressed individually, but are also referred to, for purposes
`of collective reference, as the “YouTube Streaming Services.”
`
`YouTube distributes pre-recorded video programs from YouTube’s Servers, over the
`Internet, to large numbers of users in the U.S. and elsewhere. During the relevant
`period, this was done via a “pull” protocol (as further addressed below) defined at
`the application layer and generally conforming with the MPEG-DASH specification.
`(Google is a Charter Member of the DASH Industry Forum.)
`
` A
`
` protocol similar to MPEG-DASH is HTTP Live Streaming (“HLS”). HLS is a streaming
`media delivery specification, currently published as IETF RFC 8216.
`
`This claim chart is based on evidence observed in the course of YouTube’s streaming.
`This claim chart alleges infringement based on such observations, without depending
`on whether YouTube fully complied with the MPEG-DASH or HLS standards in
`performing such streaming. However, WAG also asserts that the fact of compliance
`with either of those standards in itself separately supports all claim limitations and
`the conclusion of infringement. WAG has separately charted infringement of the
`
`Page 1 of 21
`
`Claim Language
`Overview
`
`Petitioners' Exhibit 1064
`Page 0001
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`’824, ’594, and ’636 patents that results from complying with the MPEG-DASH and
`HLS standards, and incorporates those charts herein by reference.
`
`The evidence herein is consistent with full compliance by YouTube with the MPEG-
`DASH standard from 2017-2021, and WAG believes YouTube fully complied with that
`standard during such period. WAG intends to further investigate YouTube’s
`compliance with the MPEG-DASH standard in discovery.
`
`WAG also has specific evidence of use of HLS by YouTube for certain live streams
`(see ’636 claim chart), but currently has no direct evidence of HLS having been used
`by YouTube from 2017-2021 for pre-recorded media. WAG has been impeded from
`investigating such usage in part by the fact that YouTube streams are often
`encrypted. However, there is evidence that YouTube has streamed with HLS beyond
`the specific types of sessions currently documented in these claim charts. For
`example, YouTube’s web pages (including those for pre-recorded media) also contain
`reference to a manifest for HLS, in addition to providing a link to an MPEG-DASH
`manifest. The client-side JavaScript files that YouTube distributes in support of its
`streaming media (e.g., base.js) also provide functions for HLS. YouTube web pages
`also provide links to HLS manifests (as well as MPEG-DASH manifests). HLS use by
`YouTube is further reflected in YouTube’s technical support pages, e.g.,
`https://support.google.com/youtube/answer/2853702?hl=en&ref_topic=2853712
`and https://support.google.com/youtube/answer/10349430. WAG contends that
`YouTube has supported streaming media delivery of pre-recorded programs during
`the relevant period via HLS as at least a fallback where the user device identifies
`itself as a device that normally will not support MPEG-DASH or prefers HLS. WAG
`intends to pursue discovery to investigate the foregoing and update these
`contentions as necessary.
`
`For distributing streaming media, YouTube has used its own Google Cloud Content
`Delivery Network (“CDN”) (which includes edge servers known as Google Global
`Cache (“GGC”) servers at locations including Midland, El Paso, Austin, and San
`Antonio, Texas), and also partnered with third-party providers, including without
`limitation Fastly, Cloudflare, Highwinds, Level 3, and Akamai, for CDN distribution.
`
`With regard to the infringement specifically documented herein, the pull protocol
`employed by YouTube is based on HTTP (or HTTPS) requests, which can be
`responded to through CDN servers at the network Edge that support HTTP/HTTPS
`retrieval (which most ordinary web servers are able to utilize), provided the edge
`server possesses the relevant media data elements. The same streaming
`mechanisms appear to be consistently supported through each CDN, independent of
`the type of user-agent on the client side, and in a similar manner over the respective
`CDNs.
`
`The first example shown below, from June 2020, is for a client-side device
`comprising a Chrome browser on a desktop computer. Insofar as relevant to meeting
`the limitations below, the evidence is the same in all material respects for all widely
`used browsers and devices (Chrome, Firefox, Internet Explorer, Edge, Safari, etc.),
`
`Page 2 of 21
`
`Petitioners' Exhibit 1064
`Page 0002
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`iOS, iPadOS, Android, FireOS, FireTV, Roku, TVOS and other “Smart TV” user systems,
`regardless of the CDN.
`
`Data herein such as the following, was observed through a web debugging proxy
`inserted in the communication path between a user system accessing a YouTube
`prerecorded video, and the YouTube Server (at a server in the domain
`googlevideo.com). The proxy provided is solely for data acquisition and testing
`purposes and is not in any way necessary to use YouTube’s Streaming Services, nor
`does it change any of the requests or responses while viewing video.)
`
`In addition, some of the data herein was acquired directly in a browser while
`watching various YouTube streams, using the “developer tools” and like utility
`functions built into the browser, for example, by hitting Ctrl-Shift-I and looking at the
`Network tab during playback. The same request-response patterns observed through
`a debugging proxy may also be readily observed using such developer tools built into
`the browser, on desktop and other non-embedded platforms that support full-
`featured browsers.
`
`The following is a representative example of the requests and responses observed
`(in this sample, taken in June 2020 using a proxy) in streaming a prerecorded video
`program from YouTube:
`
`
`
`
`
`The entirety of each requested video program (from beginning to end) is delivered as
`a series of time-sequenced media data elements, where each such element has been
`given one or more serial identifiers (e.g., range=9075548-11109813, rn=102), and
`requested by serial identifier, as reflected by the sample sequence above, reflecting
`11 such successive requests, interleaved with similarly sequenced requests for the
`audio portion of the program.
`
`The client-side software in these examples is responsible for requesting each such
`element, by its serial identifier, when and as needed by the client, in order to sustain
`continuous and uninterrupted playback. The overall process is sometimes referred to
`as a “pull,” in that the streaming media flow as to each element in the stream
`depends on specific client-side requests for the respective elements comprising the
`
`Page 3 of 21
`
`Petitioners' Exhibit 1064
`Page 0003
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`stream. Within the limits of the ability of the server and the communication channel
`to serve requested elements, the pacing of streaming delivery is controlled by the
`client.
`
`In order for the client’s pacing of content requests to be effective, and for playback
`of the stream on the client to continue without interruption, it should not take
`longer to request and receive the individual segments than the time it takes to play
`the segments back at a normal rendition. Repeated observations confirm that
`transmissions from YouTube Servers consistently meet these requirements. For
`example, in the below sequence, requesting and receiving video data having 3m 44
`sec of playback time only uses 1m 59sec. for the transfer, meaning that the data is
`transferred in about half the time it takes for the client system to play it back:
`
`
`
`
`
`The MPEG-DASH standard, ISO/IEC 23009, spells out media distribution steps that
`align identically with each of the claim limitations herein. The version of the MPEG-
`DASH specification referenced herein is the Fourth edition, Dec. 2019. However,
`WAG believes that YouTube also complied with earlier and later versions of this
`standard, with no differences between such versions being material to the claims
`herein.
`
`The foregoing figures are representative of every platform streaming from YouTube
`Servers for which WAG has been able to observe the contents of HTTP(S) traffic,
`including Chrome, Firefox, Safari, and other desktop browsers, iOS on iPhone and
`iPad, and Android, as well as TVOS and FireOS. It is also representative of Google
`Play Music/Youtube Music, except insofar as these audio services are limited to
`audio media data elements (still nevertheless internally named “videoplayback”).
`
`On some embedded platforms (such as Roku and TVOS), due to encryption, WAG has
`been unable to inspect the contents of HTTPS (encrypted) requests and responses.
`
`Page 4 of 21
`
`Petitioners' Exhibit 1064
`Page 0004
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`
`[1.P.1] A method
`
`
`[1.P.2] for distributing over the
`Internet,
`
`Contention
`However, the timing of the encrypted requests and responses follow the same
`pattern as observable on other platforms (e.g., desktop Chrome, as well as the
`FireOS embedded platform), and WAG believes the MPEG-DASH streaming
`implementation is the same in all material respects to the other observed
`implementations. WAG will include in its discovery requests inquiries directed to the
`additional platforms whose communications have been obscured by encryption.
`
`
`This method is performed when prerecorded streaming video programming is
`distributed by YouTube’s Servers to users in the U.S.
`
`
`The YouTube Streaming Services are accessible over the Internet through the
`youtube.com/www.youtube.com website, as well as directly from YouTube Servers
`including googlevideo.com and tv.youtube.com. For example:
`
`
`
`
`
`Activating a link on youtube.com/www.youtube.com (or similarly requesting a video
`through a Roku app or the like) results in a transmission of the streaming media over
`the Internet. For example, clicking on the “Full Chicken Fry” video results in
`transmission of that video program. Programming on YouTube ranges from short
`clips of under a minute to full-length movie, sports, news, and current events
`programs (among others), which can have durations of two or more hours. (YouTube
`live programming, addressed under separate contentions, can run continuously.)
`
`
`YouTube’s videos are distributed from servers accessible through
`youtube.com/www.youtube.com, or directly from servers such as googlevideo.com
`and tv.youtube.com:
`
`
`
`[1.P.3] from a server system
`
`Page 5 of 21
`
`Petitioners' Exhibit 1064
`Page 0005
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`
`
`[1.P.4] to one or more user
`systems,
`
`
`[1.P.5] a pre-recorded audio or
`video program
`
`
`[1.P.6] stored in digitally
`encoded form on computer-
`readable media,
`
`
`
`
`The above screen captures each reflect transmission to one user system. For any
`given video there are many users similarly situated and the server system streams
`audio/video programs to them all as recited herein.
`
`
`Each of the programs listed on the YouTube home page (e.g., “Full Chicken Fry, “35
`Times Animals Messed with the Wrong Opponent,” etc., and many others) are
`prerecorded video programs. (There is a section lower down the page for “Live”
`programming, which is separately addressed.)
`
`
`The web browser request shown above for “Full Chicken Fry,”
`
`
`https://www.youtube.com/watch?v=JVWdsyqRQWM
`
`
`reflects a request for a resource accessible to the youtube.com server. WAG does
`not have access to direct proof of how YouTube videos (and/or audio programs) are
`stored. However, a POSITA understands that the requested resource in a case such
`as shown here will reside in digitally encoded form on computer-readable media
`accessible to the server, so that the server can fulfill the user request. WAG does not
`believe YouTube will dispute this fact, and contends that an inference to support the
`fact is reasonable, whether YouTube expressly concedes the point or not, to
`establish that YouTube stores the pre-recorded video programs that it makes
`available through the YouTube Streaming Services in digitally encoded form on
`computer-readable media.
`
`Moreover, YouTube’s MPEG-DASH videos are requested by the user device, by
`successive segments of video and audio, pursuant to a manifest supplied to the user
`device by the YouTube server. Such manifests contain entries such as the following,
`
`Page 6 of 21
`
`Petitioners' Exhibit 1064
`Page 0006
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`
`[1.T] the method comprising:
`
`[1.1] reading, by at least one
`computer of the server system,
`the pre-recorded audio or
`video program from the
`computer-readable media;
`
`Contention
`indicating storage of the successive audio and video segments in a file system (or
`operationally equivalent data structure) on the YouTube servers:
`
`<SegmentList>
`<Initialization sourceURL="range/0-258"/>
`<SegmentURL media="range/460-187101"/>
`<SegmentURL media="range/187102-376159"/>
`<SegmentURL media="range/376160-561636"/>
`<SegmentURL media="range/561637-745450"/>
`<SegmentURL media="range/745451-926622"/>
`<SegmentURL media="range/926623-1114800"/>
`<SegmentURL media="range/1114801-1299024"/>
`<SegmentURL media="range/1299025-1481544"/>
`<SegmentURL media="range/1481545-1664235"/>
`<SegmentURL media="range/1664236-1844136"/>
`<SegmentURL media="range/1844137-2020117"/>
`<SegmentURL media="range/2020118-2151945"/>
`</SegmentList>
`
`The above is from the manifest for the video at
`https://www.youtube.com/watch?v=i2lhwb_OckQ (a different video, which also
`reflects a series of requests/responses by range and rn as shown in the first example
`above). This manifest is designed, per the MPEG-DASH specification, to cause the
`user device to sequentially request the listed media segments, resulting in the
`continuous playback of the subject video. It is reasonable to infer that the right side
`of each of the above expressions represents a path to a storage location of the
`corresponding segment, on the YouTube server, wherein “range” represents a
`directory (folder), and “[number]-[number]” represents a file (or an equivalent to a
`folder-file arrangement, as implemented in a database or other data structure).
`
`Even in such cases (such as with third-party CDNs) where YouTube does not actually
`own the distributing server, it nevertheless has administrative control over its
`operation, and thus directs the storage on the server of the digitally encoded media
`corresponding to the manifests it distributes and necessary to respond to user
`requests.
`
`
`
`
`WAG does not have access to direct proof that YouTube’s servers read the above-
`described pre-recorded video programs from the above-described computer-
`readable media. However, a POSITA understands that in order to serve the
`programming recorded in the media, YouTube’s servers would necessarily have to
`perform this claim step. WAG contends that this inference, which it does not believe
`YouTube will dispute, is sufficient, whether YouTube expressly concedes the point or
`not, to establish that the computers comprising YouTube’s server system read the
`
`Page 7 of 21
`
`Petitioners' Exhibit 1064
`Page 0007
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`
`[1.2.1] supplying, at the server
`system, media data elements
`representing the program,
`
`Contention
`above-described pre-recorded video programs from the above-described computer-
`readable media.
`
`
`The figure above, again, but now focusing on the right-hand side, showing the
`request and corresponding response,
`
`
`
`
`
`shows one user request and corresponding server response, for one media data
`element in a sequence of many such elements (each similarly requested and
`provided) comprising the requested program stream (e.g., the entire requested
`video, which can go on for many minutes or in some cases hours), from beginning to
`end.
`
`The media data element requested in the above figure is one of a plurality of media
`data elements representing the requested program.
`
`
`WAG does not have access to direct proof that YouTube supplies, at its server
`system, media data elements corresponding to these requests. However, a POSITA
`understands that in order to serve the media data elements comprising the
`requested program, and have them received, as indicated by the “200 OK” “success”
`HTTP response code, they each necessarily must be supplied at the server system.
`The manifest noted above also shows that the server supplies the media data
`elements representing the program. WAG contends that this inference, based on an
`observed series of user requests for such elements, and corresponding responses,
`proximate to each other in time, which it does not believe YouTube will dispute, is
`sufficient, whether YouTube expressly concedes the point or not, to establish that
`
`Page 8 of 21
`
`Petitioners' Exhibit 1064
`Page 0008
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`
`[1.2.2] each media data
`element comprising a digitally
`encoded portion of the
`program
`
`Contention
`the computers comprising YouTube’s server system perform the step, under
`YouTube’s direction and control, of supplying each requested element to the server
`in order for WAG to have been able to observe and record the corresponding
`responses.
`
`Furthermore, the fact that YouTube serves a manifest (see 1.P.6 above), listing URLs
`on the specified server for the successive media segments comprising the requested
`program, reflects that YouTube has supplied the listed media data elements,
`representing the program, at the server.
`
`In the above example, the requested element comprises 2,034,266 bytes (1.94MB in
`binary), representing a portion (one of a large number requested over the course of
`receiving the program) of the requested program. The metadata shown (200 OK)
`reflects that the element received is what was requested, corresponding to the
`request parameters (including range: 9075548-11109813 and rn: 102).
`
`This represents one portion of the program, as reflected by the following summary
`timeline for the series of requests that included the above individual request (the
`recorded section representing 21 successive audio and video requests for media
`having 231.3 seconds duration). The following represents requests for the period
`recorded in the portion of the session shown in this data capture. The above
`individual request/response (for 1.94MB) corresponds to the first line of this
`summary:
`
`
`
`[1.2.3] and having a playback
`rate;
`
`
`[1.3.1] serially identifying the
`media data elements,
`
`
`
`
`The requested media data element is digitally encoded at a bitrate range and
`framerate such that a normal rendition occurs when played back at that framerate,
`i.e., when each is played back in the corresponding time period set out in the above
`listing.
`
`The elements in this example are serially identified by parameters including “range”
`and “rn” as specified in the request headers and query string. Such identification
`takes place at least when the data element is stored on a storage device accessible
`to the server, when a manifest is created, and when the server responds to a
`request.
`
`The “range” and “rn” values, both individually and as an ordered pair, literally
`provide serial identification of the media data elements. Nonetheless, this limitation
`
`Page 9 of 21
`
`Petitioners' Exhibit 1064
`Page 0009
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`
`[1.3.2] said serial identification
`indicating a time sequence of
`the media data elements;
`
`Contention
`may also be found under the doctrine of equivalents. In particular, the function of
`serially identifying the media data elements is to uniquely identify the time-
`sequenced media data elements from each other, which is exactly what the “range”
`and “rn” values do, both individually and as an ordered pair. The way in which the
`media data elements are uniquely identified is to provide each with a unique
`identifier that can be used in requests from the client to the server; the unique
`“range” and “rn” values associated with each media data element perform this
`function, both individually and as an ordered pair. The result of the serial
`identification is that the client and server agree upon identifications that allow the
`client to uniquely request a media data element in the proper time sequence, which
`is what occurs when the client uses the “range” and/or “rn” values to specify a
`desired media data element.
`
`The time-sequenced character of the successive elements in a transmission is
`reflected in the summary timeline above, again:
`
`
`
`
`
`The rn numbers generally increment by 1 for each request. (The numbering for
`videos on the YouTube Web Site counts both the video and interleaved audio
`segments, and occasionally a number can be missing.) In this sequence, the “range”
`identifiers increment for each successive segment. After initialization, the rn
`numbers likewise increment by 1 for each segment, in this case for segment 104 and
`each following segment. An example later in this sequence is rn=110:
`
`
`
`
`
`
`Page 10 of 21
`
`Petitioners' Exhibit 1064
`Page 0010
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`The same can also be directly observed (without the intermediate proxy) on a full-
`featured browser used to access the YouTube Streaming Services, by invoking its
`Developer Tools (typically, Ctrl-Shift-I).
`
`The above pattern, showing a continuous time sequence of elements comprising the
`requested stream, corresponding to the serial identification of the elements, is
`representative of all request-response sequences observed with the YouTube
`Streaming Services, regardless of the time of observation during the period from
`patent issuance through March 2021, regardless of the CDN being utilized, and
`regardless of the user media playing platform. In many cases (as shown here) the
`audio is part of the numbering, and in others (e.g., live, in a separate claim chart) the
`rn numbers are just for the video, and likewise, for the audio, in the case of music
`streaming. In all cases, the range numbers also progress serially.
`
`The following are corresponding request-response timelines for other platforms
`streaming from YouTube Streaming Services:
`
`Google Music (Rod Stewart song Maggie May, requests/responses captured in
`Chrome Developer Console on a desktop computer:
`
`
`
`First segment (above), range: 0-66403, rn: 1
`
`
`
`Page 11 of 21
`
`Petitioners' Exhibit 1064
`Page 0011
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`
`
`Second segment, range: 66404, rn: 2 (both next in sequence); the following
`videoplayback elements follow the same pattern.
`
`iOS:
`
`
`
`
`
`YouTube on iOS (as captured by a proxy) shows the same patterns, with successively
`incrementing range and rn identifiers for the respective media segments.
`
`WAG has also been able to intercept successive requests and responses of
`characteristic length for streaming YouTube media to tvOS and FireOS devices, but
`
`
`
`Page 12 of 21
`
`Petitioners' Exhibit 1064
`Page 0012
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`encryption has prevented WAG from seeing the identifiers exchanged. For example,
`a packet capture for a YouTube streaming session from tvOS showed the following:
`
`
`
`
`
`WAG believes these embedded platforms (e.g., tvOS, FireOS, etc., as well as Roku
`during the relevant period) operated with YouTube in substantially the same way as
`observed for desktop and iOS devices. WAG will include in its discovery requests
`inquiries directed to the additional platforms whose communications have been
`obscured by encryption.
`
`(The YouTube Live transmissions, covered in a separate claim chart, have “sq”
`numbers in the requests (in addition to rn), which are also sequential.)
`
`Additionally, the list of media data elements in the manifest noted above, each
`uniquely identified by its respective range number, also provides serial identification
`indicating the time sequences of the respective media data elements. Hence, not
`only is time sequencing of the media data elements indicated by progressive
`increasing of the “range” and/or “rn” values, but also by the relative positioning of
`the identified media data element within the manifest, with media data elements
`appearing higher (or first) in the manifest being earlier in time.
`
`As noted above, the elements in streaming media requests to YouTube’s Streaming
`Services are serially identified by serial identifiers including “range” and “rn” as
`specified in the request and response. WAG cannot directly see how YouTube stores
`the media data elements comprising its recorded programs in data structures on (or
`under the control of) its servers. However, WAG believes that, since the requests are
`successful, that corresponding elements (which conform to the requested ranges
`and rn parameters) are stored on the server. Moreover, as discussed above, the
`captured manifest data also reflects that the media data elements are stored on the
`server in a folder/file data structure (or in an equivalent layout in a database or other
`data structure), wherein the folder is named “range” and the respective files have
`the corresponding byte range (“[number]-[number]”) as a filename.
`
`The diagrams above (both the requests and responses, and the associated timeline)
`show that the intermediate proxy intercepted requests being made from a user
`
`Page 13 of 21
`
`
`[1.4] storing the media data
`elements in a data structure
`under the control of the server
`system;
`
`
`[1.5.1] receiving requests at the
`server system via one or more
`
`Petitioners' Exhibit 1064
`Page 0013
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`data connections over the
`Internet,
`
`
`[1.5.2] for one or more of the
`media data elements stored in
`the data structure,
`
`
`[1.5.3] each received request
`specifying one or more serial
`identifiers of the requested one
`or more media data elements,
`
`[1.5.4] each received request
`originating from a requesting
`user system of the one or more
`user systems; and
`
`[1.6.1] responsive to the
`requests, sending, by the
`server system, the one or more
`media data elements having
`the one or more specified serial
`identifiers,
`
`[1.6.2] to the requesting user
`systems corresponding to the
`requests;
`
`[1.W] wherein
`
`[1.W.1] the data connection
`between the server system and
`each requesting user system
`has a data rate more rapid than
`the playback rate of the one or
`more media data elements
`sent via that connection;
`
`
`Contention
`system over Internet data connections, to YouTube servers, and time-proximate
`response thereto, reflecting the same serial identification as the corresponding
`request. WAG contends it is therefore reasonable to infer that the YouTube server
`received the request.
`
`
`See examples in 1.3.2. The shown GET requests for the element identified by serial
`identifiers, including “range” and “rn” (and in some cases by both rn and sq
`numbers), from a specified resource (in the URL) reflects receiving a request for one
`or more media data elements stored in the data structure. The MPEG-DASH
`specification also provides for the client to request one or more media data
`elements stored in a data structure on the server, and the observed YouTube
`manifests (see example above) confirm compliance with that aspect of the
`specification.
`
`See 1.5.2.
`
`
`The intercepting proxy (or alternately the browser’s Developer Tools console)
`verifies that the request came a requesting user system.
`
`
`Reflected in all of the responses intercepted by the intermediate proxy, as shown in
`the various diagrams herein, and directly reflected in Developer Tools windows on
`the browsers that support such tools. The result code 200 OK shown in the captures
`confirm success in this regard.
`
`
`The responses corresponding to the requests go the requesting user system; see
`1.6.1. The response can be viewed (as data) in the Developer Console, as well as
`rendered on the user device display and audio output.
`
`
`
`As seen with respect to 1.3.2, requests are made every few seconds (reflecting that
`the elements corresponding to the element serial ID take the corresponding number
`of seconds to play back), whereas element is generally transmitted in well under a
`second. It is reasonable to infer, therefore, that the data connection had a data rate
`in excess of the playback rate.
`
`
`
`Page 14 of 21
`
`Petitioners' Exhibit 1064
`Page 0014
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`[1.W.2] each sending is at a
`transmission rate as fast as the
`data connection between the
`server system and each
`requesting user system allow;
`
`
`[1.W.3] the one or more media
`data element sent are selected
`without depending on the
`server system maintaining a
`record of the last media data
`element sent to the requesting
`user systems;
`
`Contention
`WAG does not have access to YouTube’s servers, but states that is not aware of, and
`sees no evidence of, any process on YouTube’s servers, or any routine in the client-
`side code that YouTube supplies for the user devices, that in any way throttles the
`data connection. WAG contends that it is therefore reasonable to infer that as a
`result of the observed time sequence of requests and responses, and the inferred
`playback duration of each of t