UNITED STATES DISTRICT COURT
`FOR THE WESTERN DISTRICT OF TEXAS
`WACO DIVISION
`
`
`
`
`WAG ACQUISITION, L.L.C.,
`
`
`v.
`
`GOOGLE LLC and
`YOUTUBE, INC.,
`
`
`
`Plaintiff,
`
`Defendants.
`
`§
`§
`§
`§
`§
`§
`§
`§
`§
`§
`§
`
`No. 6:21-cv-00816-ADA
`
`Jury Trial Demanded
`
`
`
`WAG ACQUISITION, L.L.C.’S PRELIMINARY INFRINGEMENT CONTENTIONS
`
`Pursuant to the Honorable Judge Albright’s Standing Order Governing Proceedings –
`
`Patent Cases (Dkt. No. 16 ¶ 2), Plaintiff WAG Acquisition, L.L.C., through the undersigned
`
`counsel, hereby serves its preliminary infringement contentions on Defendants Google LLC and
`
`YouTube, Inc.1 (“Defendants”).
`
`The attached charts for U.S. Patent Nos. 9,742,824; 9,729,594; and 9,762,636 lay out the
`
`claims Defendants are accused of infringing and set forth where in the accused products each
`
`element of the asserted claims is found.
`
`All claims asserted herein are entitled to the priority date (i.e., the earliest date of
`
`invention) of November 11, 1999.
`
`Plaintiff is producing, concurrent herewith, documents evidencing conception and
`
`reduction to practice for each claimed invention and a copy of the file history for each of the
`
`
`1 Plaintiff understands that, per Defendants’ Rule 7.1 Statement, YouTube, Inc. should be listed
`as YouTube LLC. Dkt. No. 18 at 1 n.1.
`
`
`
`1
`
`Petitioners' Exhibit 1047
`Page 0001
`
`

`

`patents-in-suit. Plaintiff has made a good faith effort to produce documents evidencing
`
`conception and reduction to practice. Should Plaintiff identify additional relevant documents,
`
`Plaintiff will supplement this production.
`
`Plaintiff reserves the right to amend these contentions in light of discovery, which has not
`
`yet begun, as well as to take into account any claim construction rulings that the Court may
`
`issue.
`
`Plaintiff has marked the accompanying claim charts as Confidential pursuant to the
`
`interim Protective Order issued in this case. Dkt. No. 16 at 3.
`
`
`
`
`
`
`
`HALEY & OLSON, P.C.
`100 North Ritchie Road, Suite 200
`Waco, Texas 76712
`Tel: (254) 776-3336
`Fax: (254) 776-6823
`
`By: s/ Brandon R. Oates
`Brandon R. Oates (State Bar No. 24032921)
`Email: boates@haleyolson.com
`
`OF COUNSEL:
`
`LISTON ABRAMSON LLP
`The Chrysler Building
`405 Lexington Ave, 46th Floor
`New York, New York 10174
`Tel: (212) 257-1630
`Ronald Abramson (Admitted pro hac vice)
`David G. Liston (Admitted pro hac vice)
`Ari J. Jaffess (Admitted pro hac vice)
`Alex G. Patchen (Admitted pro hac vice)
`M. Michael Lewis (Admitted pro hac vice)
`Gina K. Kim
`Email: docket@listonabramson.com
`
`Attorneys for Plaintiff WAG Acquisition, L.L.C.
`
`2
`
`Petitioners' Exhibit 1047
`Page 0002
`
`

`

`CERTIFICATE OF SERVICE
`
`I, Ronald Abramson, hereby certify that on this day a true and correct copy of the
`
`foregoing document, WAG Acquisition, L.L.C.’s Preliminary Infringement Contentions, was
`
`served on all attorneys of record for Defendants via electronic mail.
`
`
`
`
`
`Dated: November 15, 2021
`
`
`
`/s/ Ronald Abramson
`
`Ronald Abramson
`
`
`
`
`
`
`
`
`
`
`
`Petitioners' Exhibit 1047
`Page 0003
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`Overview
`
`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 patent addressed in these
`contentions, through the common date of expiration of the patent
`(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 defined at the application layer and generally conforming
`with the MPEG-DASH specification. (Google is a Charter Member of
`the DASH Industry Forum.) YouTube’s web pages also contain
`reference to a manifest for HTTP Live Streaming (“HLS”), in addition
`to providing a link to an MPEG-DASH manifest. HLS is a streaming
`media delivery specification, specified in IETF RFC 8216. Systems in
`
`Page 1 of 22
`
`Petitioners' Exhibit 1047
`Page 0004
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`the U.S. that distribute streaming media in accordance with the HLS
`specification infringe WAG’s patents asserted herein on
`substantially the same facts shown herein with respect to
`YouTube’s use of MPEG-DASH. The client-side JavaScript files that
`YouTube distributes in support of its streaming media (e.g., base.js)
`also provide functions for HLS and YouTube web pages provide links
`to HLS manifests as well as MPEG-DASH manifests. WAG contends
`that YouTube has 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.
`
`YouTube has used its own Google Cloud 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.
`
`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 (as most
`ordinary web servers do), 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.) iOS,
`iPadOS, Android, FireOS, FireTV, Roku, TVOS and other “Smart TV”
`user systems, regardless of the CDN.
`
`The MPEG-DASH form of distribution is reflected in data such as the
`following, 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). The same request-
`response patterns may also be readily observed, on desktop and
`other non-embedded platforms supporting full-featured browsers,
`through the “developer tools” and like utility functions built into
`
`Page 2 of 22
`
`Petitioners' Exhibit 1047
`Page 0005
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`the browsers, for example, by hitting Ctrl-Shift-I and looking at the
`Network tab during playback. 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. Because 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.”
`
`Furthermore, in order for the client to successfully keep up with the
`stream while making such pull requests, 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:
`
`
`Page 3 of 22
`
`Petitioners' Exhibit 1047
`Page 0006
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`
`
`
`
`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. 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.
`
`
`
`Page 4 of 22
`
`
`
`Petitioners' Exhibit 1047
`Page 0007
`
`

`

`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
`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 22
`
`Petitioners' Exhibit 1047
`Page 0008
`
`

`

`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.
`
`
`Page 6 of 22
`
`Petitioners' Exhibit 1047
`Page 0009
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`
`[1.T] the method comprising:
`
`
`Contention
`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, 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.
`
`
`
`
`
`Page 7 of 22
`
`Petitioners' Exhibit 1047
`Page 0010
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`[1.1] reading, by at least one
`computer of the server system,
`the pre-recorded audio or
`video program from the
`computer-readable media;
`
`
`[1.2.1] supplying, at the server
`system, media data elements
`representing the program,
`
`Contention
`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 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.
`
`
`Page 8 of 22
`
`Petitioners' Exhibit 1047
`Page 0011
`
`

`

`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
`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.
`
`
`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:
`
`
`
`
`
`
`
`
`Page 9 of 22
`
`Petitioners' Exhibit 1047
`Page 0012
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`[1.2.3] and having a playback
`rate;
`
`
`[1.3.1] serially identifying the
`media data elements,
`
`
`[1.3.2] said serial identification
`indicating a time sequence of
`the media data elements;
`
`Contention
`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 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
`
`
`
`Page 10 of 22
`
`Petitioners' Exhibit 1047
`Page 0013
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`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:
`
`
`
`
`
`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:
`
`
`Page 11 of 22
`
`Petitioners' Exhibit 1047
`Page 0014
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`
`
`First segment (above), range: 0-66403, rn: 1
`
`
`Second segment, range: 66404, rn: 2 (both next in sequence); the
`following videoplayback elements follow the same pattern.
`
`iOS:
`
`
`
`
`
`
`Page 12 of 22
`
`Petitioners' Exhibit 1047
`Page 0015
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`Contention
`
`
`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 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
`
`
`
`
`
`Page 13 of 22
`
`Petitioners' Exhibit 1047
`Page 0016
`
`

`

`US 9,742,824 (Pull-Recorded) – 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;
`
`
`[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
`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 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
`
`Page 14 of 22
`
`Petitioners' Exhibit 1047
`Page 0017
`
`

`

`US 9,742,824 (Pull-Recorded) – Compared to: YouTube
`
`Confidential Under Interim Protective Order
`
`Claim Language
`
`
`[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;
`
`[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
`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 th