US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Contention
`WAG has asserted three patents against 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 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, addressed herein, corresponds to the ’824 patent in certain respects, but
`concerns live media. Because the subject matter of these patents overlap, WAG’s
`infringement contentions with regard to the ’824 and ’594 patents are each
`incorporated herein by reference.
`
`YouTube LLC and/or affiliated entities such as Google LLC (“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 live streaming video program accessible from or
`through the YouTube Site (including without limitation the “Live” section of the
`YouTube Web Site as well as the YouTube TV subscription service), for the period
`from the respective 2017 issuance dates of the patents addressed in these
`contentions, through the common date of expiration of the patents (March 28, 2021).
`They further relate to live videos streamed from YouTube’s Servers (e.g.,
`googlevideo.com, tv.youtube.com) to embedded “YouTube” devices and apps. The
`foregoing services are addressed individually, but are also referred to, for purposes of
`collective reference, as the “YouTube Streaming Services.”
`
`YouTube distributes live 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
`of live content. 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 ’824, ’594, and ’636 patents that results from complying with the
`MPEG-DASH and HLS standards, and incorporates those charts herein by reference.
`
`
`Page 1 of 26
`
`Claim Language
`Overview
`
`Petitioners' Exhibit 1063
`Page 0001
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`The evidence herein is consistent with full compliance by YouTube with the MPEG-
`DASH and HLS standards for distributing live programming from 2017-2021, and WAG
`believes YouTube fully complied with those standards during such period. WAG
`intends to further investigate YouTube’s compliance with the MPEG-DASH and HLS
`standards in discovery.
`
`WAG also has specific evidence (as set forth herein) of use of HLS by YouTube for
`certain live streams. There is also evidence that YouTube has streamed with HLS
`beyond the specific types of sessions currently documented in this claim chart. For
`example, YouTube’s web pages 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. WAG contends that YouTube has also supported streaming media
`delivery 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 October 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 or players (Chrome, Firefox, Internet Explorer, Edge, Safari, etc.), 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 live
`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.)
`
`
`Page 2 of 26
`
`Petitioners' Exhibit 1063
`Page 0002
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`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 February 2021 using a proxy) in streaming a live video program
`from YouTube:
`
`
`
`
`
`
`
`The above trace from a live YouTube transmission shows a request for a media data
`element identified by an “sq” identifier, 5174732 (as well as an “rn” identifier of 4).
`The entirety of the portion watched of each requested live video program (from
`beginning to end of watching) 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., sq=516042 etc.), and requested by serial identifier, as reflected by the sequence
`which was recorded and shown here (on the left side of the figure) for a number of
`
`Page 3 of 26
`
`Petitioners' Exhibit 1063
`Page 0003
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`successive requests of this type (interleaved for the audio and video segments
`comprising the stream), as shown above.
`
`The client-side software 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 is thus dependent on
`specific client-side requests for the respective elements comprising the stream, the
`overall process is sometimes referred to as a “pull.” 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, the following is a graph of data flow for a YouTube live transmission in
`February 2021, which shows bursts of rapid data transfer in response to requests,
`followed by quiet periods between the requests, reflecting that the data elements are
`each being sent in less time than it takes to play them 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 live
`programming 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.
`
`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.
`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
`
`Page 4 of 26
`
`Petitioners' Exhibit 1063
`Page 0004
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`
`[1.P.1] A method
`
`
`[1.P.2] for distributing a live
`audio or video program over
`the Internet,
`
`Contention
`include in its discovery requests inquiries directed to the additional platforms whose
`communications have been obscured by encryption.
`
`
`This method is performed when live streaming video programming is distributed by
`YouTube’s Servers to users in the U.S.
`
`
`The YouTube Streaming Services for live performances are accessible over the
`Internet through the youtube.com/www.youtube.com website, from YouTube TV, as
`well as directly from YouTube Servers including googlevideo.com and tv.youtube.com.
`For example, the following figure shows a game being played, on a live stream (in
`January 2021):
`
`
`
`[1.P.3] from a server system
`
`
`[1.P.4] to a plurality of user
`systems,
`
`
`
`
`Activating a link on the “Live” section of youtube.com/www.youtube.com, or
`YouTube TV (or similarly requesting a video through a Roku app or the like) results in
`a transmission of the streaming media over the Internet for the live performance.
`YouTube live programming can run at scheduled times, or continuously, e.g., for a
`News channel.
`
`
`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. See 1.P.2.
`
`
`The above screen capture reflects a transmission to one user system. Google aims to
`have a large audience for its live transmissions, and for any given video there are
`many users similarly situated such that the server system supports a plurality of user
`systems.
`
`
`Page 5 of 26
`
`Petitioners' Exhibit 1063
`Page 0005
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`
`[1.T] the method comprising:
`
`[1.1] receiving at the server
`system a continuous digitally
`encoded stream for the audio
`or video program, via a data
`connection from a live source,
`in real time, the server system
`comprising at least one
`computer;
`
`[1.2] upon receipt of the
`stream by the server system
`
`
`[1.2.1] supplying, at the server
`system, media data elements
`representing the program,
`
`Contention
`
`
`
`
`A POSITA understands that in order to serve live programming, YouTube’s servers
`would necessarily have to perform this claim step, i.e., receive the stream from a live
`source, e.g., a feed from a webcam or a digital feed from a media outlet such as a TV
`station. 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 performs this step.
`
`
`
`Since the object is to provide programming contemporaneously with the
`performance, WAG contends that it is a reasonable inference that YouTube performs
`the following steps upon its systems’ receipt of the live feed.
`
`The figure above, again, but now focusing on the right-hand side, showing the request
`and corresponding response,
`
`
`Page 6 of 26
`
`Petitioners' Exhibit 1063
`Page 0006
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`
`
`
`
`Page 7 of 26
`
`Petitioners' Exhibit 1063
`Page 0007
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`
`
`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 many cases continuously), from beginning to
`end of the portion being watched.
`
`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 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.
`
`The manifest for a live YouTube program (showing the most recent entries) also
`reflects that the YouTube server informs the client system that streaming media data
`elements representing the program have been supplied at the server:
`
`</SegmentList>
`[Many preceding sequential entries like the below … ]
`<SegmentURL media="sq/2698308/lmt/1636893105779885"/>
`<SegmentURL media="sq/2698309/lmt/1636893105779900"/>
`<SegmentURL media="sq/2698310/lmt/1636893105779915"/>
`<SegmentURL media="sq/2698311/lmt/1636893105779930"/>
`<SegmentURL media="sq/2698312/lmt/1636893105779945"/>
`<SegmentURL media="sq/2698313/lmt/1636893105779960"/>
`<SegmentURL media="sq/2698314/lmt/1636893105779975"/>
`<SegmentURL media="sq/2698315/lmt/1636893105779990"/>
`<SegmentURL media="sq/2698316/lmt/1636893105780005"/>
`</SegmentList>
`
`where the string “sq/[number]/lmt/[number]” given for each element represents a
`path to where the element is stored on the server. (WAG believes that the appended
`“lmt” number is a timestamp, used to avoid playing outdated segments.)
`
`Another example of a YouTube manifest for live programming is for HLS, used where
`YouTube serves live content to an iPhone running the Safari browser:
`
`Page 8 of 26
`
`Petitioners' Exhibit 1063
`Page 0008
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`
`
`The following shows a manifest from such a session (sometimes called a “playlist” in
`the context of HLS):
`
`
`
`
`
`The serial identifiers are encoded into the paths of the element URLs listed in the
`manifest. However, the path strings are too long to see in full in the above illustration.
`The following is an example of the full string for one of the paths shown above:
`
`https://rr3---sn-n4v7sn76.googlevideo.com/videoplayback/id/w_Ma8oQLmSM.6/itag/91/sou
`rce/yt_live_broadcast/cpn/nQXzHG0q6kO2pCzU/expire/1643953691/ei/u2n8YZu0Ftqokwbh44GA
`DA/ip/107.77.205.225/requiressl/yes/ratebypass/yes/live/1/sgoap/gir%3Dyes%3Bitag%3D1
`39/sgovp/gir%3Dyes%3Bitag%3D160/hls_chunk_host/rr3---sn-n4v7sn76.googlevideo.com/pla
`ylist_duration/30/manifest_duration/30/vprv/1/playlist_type/DVR/initcwndbps/1560/mh/
`wG/mm/44/mn/sn-n4v7sn76/ms/lva/mv/m/mvi/3/pl/24/keepalive/yes/fexp/24001373,24007246
`/c/MWEB/cver/2.20220203.00.00/ptk/youtube_single/oid/780ppdhJy5EF19q2zyC3vA/ptchn/Bi
`2mrWuNuyYy4gbM6fU18Q/pltype/contentlive/mt/1643931877/sparams/expire,ei,ip,id,itag,s
`ource,requiressl,ratebypass,live,sgoap,sgovp,playlist_duration,manifest_duration,vpr
`v,playlist_type/sig/AOq0QJ8wRAIgEwitwqMMf2W7prkE5ddaLtJRyRLt45vd-fPR7B_4F8MCIE6FFxmh
`oHScQ6Sc0tUtz3SEogrdISAYhhFFNC-8FfqU/lsparams/hls_chunk_host,initcwndbps,mh,mm,mn,ms
`,mv,mvi,pl/lsig/AG3C_xAwRgIhAOIUmpDRbm4qsekZPcd-rn3lNO6Pxvxrq-rZtwlP0NDCAiEAppU1vL4v
`gE65_GG3AY5l1t-aLFwtL-d3Uh3o7RW_nq8%3D/playlist/index.m3u8/sq/4099018/goap/clen%3D31
`705%3Blmt%3D1643862205978976/govp/clen%3D26795%3Blmt%3D1643862205978979/dur/5.005/fi
`le/seg.ts
`
`The paths in successive lines of the manifest are distinguished from each other by an
`/sq/[number] sequence as shown (highlighted) in the example above.
`
`The following are alternate views of this data, showing the sequence in the example
`stream:
`
`
`
`
`Page 9 of 26
`
`Petitioners' Exhibit 1063
`Page 0009
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`
`
`Contention
`
`
`[1.2.2] each media data
`element comprising a digitally
`encoded portion of the
`program
`
`
`
`
`Though these captures were taken after patent expiration, WAG believes they are
`representative of corresponding transmissions during the term, insofar as YouTube
`supported Safari on the iPhone, and Safari has always lacked Media Source Extensions
`(“MSE”).
`
`
`In the first above example (sq = 5174732), the requested element comprises 136,698
`bytes, 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 sq and rn).
`
`This represents one portion of the program, as reflected by the timeline on the left of
`the below figure for the series of requests that included the above individual request
`(highlighted).
`
`
`Page 10 of 26
`
`Petitioners' Exhibit 1063
`Page 0010
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`
`
`
`Further in the same stream, the following was recorded:
`
`
`
`
`Page 11 of 26
`
`Petitioners' Exhibit 1063
`Page 0011
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`
`
`Hence, each of these media data elements comprises a digitally encoded portion of
`the program.
`
` A
`
` like pattern is reflected for HLS, as shown in the following summary, showing
`successive seg.ts elements comprising a digitally encoded portion of the program:
`
`
`
`[1.2.3] and having a playback
`rate;
`
`
`
`
`
`
`
`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
`listings.
`
`
`Page 12 of 26
`
`Petitioners' Exhibit 1063
`Page 0012
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`[1.3.1] serially identifying the
`media data elements,
`
`
`[1.3.2] said serial identification
`indicating a time sequence of
`the media data elements, and
`
`Contention
`The elements in the first example are serially identified by parameters including “sq”
`and “rn” as specified in the request headers and query string (and as reflected in the
`manifest, for sq). 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 “sq” and “rn” values, both individually and as an ordered pair, literally provide
`serial identification of the media data elements. Nonetheless, this limitation 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 “sq” 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 “sq” 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 “sq” and/or
`“rn” values to specify a desired media data element.
`
`For HLS, the serial identifiers correspond to the paths of the element URLs listed in
`the manifest, distinguished from one another by the /sq/[number] sequence in each
`path.
`
`
`The time-sequenced character of the successive media data elements in a
`transmission is reflected in the timeline of requests, see 1.2.2. above.
`
`The sq and rn numbers generally increment by 1 for each request.
`
`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. In all cases, the range numbers also progress serially.
`
`The following are corresponding request-response timelines for other performances
`and platforms streaming from YouTube Streaming Services:
`
`NBC News (Live) October 2020:
`
`
`Page 13 of 26
`
`Petitioners' Exhibit 1063
`Page 0013
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`
`
`
`Video segment, sq: 8008, rn: 4)
`
`
`Next Video Segment (sq: 8009, rn: 5)
`
`
`Next Video Segment (sq: 8010, rn: 6)
`
`
`
`
`
`
`
`
`Page 14 of 26
`
`Petitioners' Exhibit 1063
`Page 0014
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`
`
`Desktop captures from July 2000:
`
`
`
`
`
`
`
`
`
`
`
`
`Page 15 of 26
`
`Petitioners' Exhibit 1063
`Page 0015
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`
`
`Note that in both of these examples, sq and rn are both serial, sq is sequential for
`video and audio (in separate sequences) and rn is sequential for audio + video.
`
`HLS exhibits a similar pattern:
`
`
`
`
`
`
`
`
`
`(Although observed in 2022, WAG believes the usage was the same for 2017-2021
`because the Safari browser on the iPhone has consistently lacked MSE and did not
`support MPEG-DASH.)
`
`WAG has also been able to intercept successive requests and responses of
`characteristic length for streaming YouTube media to tvOS devices, but encryption
`has prevented WAG from seeing the identifiers exchanged. For example, a packet
`capture for a YouTube streaming session from tvOS showed the following:
`
`
`
`
`Page 16 of 26
`
`Petitioners' Exhibit 1063
`Page 0016
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`
`[1.4] storing the media data
`elements in a data structure
`under the control of the server
`system;
`
`Contention
`
`
`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.
`
`Additionally, the list of media data elements in the manifest noted above, each
`uniquely identified by its respective “sq” 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 “sq” 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 “sq” and “rn” as specified
`in the request and response. WAG cannot directly see how YouTube stores the media
`data elements comprising its live 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 sq 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 containing the corresponding segment is a subfolder named with the sq
`number, situated under a parent folder named “sq”. (There is also with an appended
`“lmt” subfolder, which WAG believes represents a timestamp.)
`
`The URLs provided for HLS follows the same data layout, i.e., folders named sq, and
`serially identified (numbered) folders beneath each sq folder:
`
`
`
`
`
`
`
`
`
`Page 17 of 26
`
`Petitioners' Exhibit 1063
`Page 0017
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`[1.5.1] receiving requests at the
`server system via one or more
`data connections over the
`Internet,
`
`
`[1.5.2] for one or more of the
`media data elements stored in
`the data structure,
`
`Contention
`The diagrams above (both the requests and responses, and the associated timeline)
`show that the intermediate proxy intercepted requests being made from a user
`system over Internet data connections, to YouTube servers, and time-proximate
`response thereto, reflecting the same serial identification as the corresponding
`request, with the return code 200 OK. 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 “sq” and “rn”, 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.
`
`Requests for successive elements stored on the server is also reflected for HLS:
`
`
`
`[1.5.3] each received request
`specifying one or more serial
`identifiers of the requested one
`or more media data elements,
`
`
`
`
`See 1.5.2
`
`
`
`
`
`Page 18 of 26
`
`Petitioners' Exhibit 1063
`Page 0018
`
`

`

`US 9,762,636 (Pull-Live) – Compared to: YouTube
`
`
`
`Confidential Under Interim Protective Order
`
`Claim Language
`[1.5.4] each received request
`originating from a requesting
`user system of a plurality of
`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;
`
`
`[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;
`
`Contention
`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 go the requesting user systems corresponding to the requests; 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 each 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.
`
`Likewise for HLS (see capture in 1.2.2, reflecting receipt of five-second segments in
`about 1 second each).
`
`
`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 the elements, that each sending is at a transmissio