WAG Slides
`IPR2022-01412, -01413
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`1 of 40
`
`
`IPR2022-01412, -01413
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`1 of 40
`
`
`
`SCOPE AND CONTENT OF THE PRIOR ART (CARMEL)
`
`As a factual matter, the scope and content of Carmel concerns:
`
`• The object of performing internet streaming from commonly available
`hardware using widely supported standards.
`
`• Dividing the stream into time-sequenced slices in one or more encodings.
`
`• Transmitting the slices at the selected encoding to the user system, beginning
`with the most recently available slice or an earlier slice as may be selected by
`the user.
`
`• Seeking to sustain the transmission of the successive slices at a rate generally
`equal to the rate at which the slices are being generated, so as not to get
`ahead of or fall behind the program.
`
`• Commonly known as “push”.
`
`POR at 24-36.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`2 of 40
`
`
`
`DIFFERENCES BETWEEN CLAIMED SUBJECT MATTER AND THE PRIOR ART
`
`• Claimed Subject Matter:
`
`o Analysis must address each and every limitation, and the claims as a whole.
`
`o It is impossible for an internet streaming mechanism to comply with all of the
`’824 claim limitations unless –
`
`• Content is divided into a plurality of time-sequenced elements.
`
`• The client originates successive requests that identify by serial ID each and
`every element to be sent in response to each successive request.
`
`• Prior Art:
`
`o Carmel discloses only a single request to start a stream from a specified
`starting point.
`
`OBVIOUSNESS ANALYSIS MUST BE CONSISTENT WITH THE ABOVE FINDINGS
`POR at 1-2, 4-6, 24, 26-27, 31-36; Sur-reply at 10-22.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`3 of 40
`
`
`
`PETITION RELIES ON BOTH FIGS. 6A AND 6B OF CARMEL FOR “INDIVIDUAL
`REQUEST” [MIS]CHARACTERIZATION
`
`• Pet. at 26: “the request for a particular slice of data stream 40 specifies the
`serial indicator (slice index) of the requested slice … Carmel Figure 6A confirms
`this process is repeated for each slice.”
`
`• Pet. at 29: “Carmel teaches that after the client 30 selects a particular slice,
`the client 30 downloads that slice. (Polish, ¶138; Carmel, 8:1-11, 8:32-41; see
`also id., 2:1-21, 3:63-66, 4:7-11, 10:24-54, Figs. 6A and 6B, 13:30-35.)”
`
`• Pet. at 38: “Figures 6A and 6B show that Carmel reflects a classic ‘client-pull’
`streaming system where the data recipient is responsible for selecting the data
`to be transmitted.”
`
`• Pet. at 40: “data slices are sent by the server 36 only in response to requests
`from clients 30 … this confirmed by Figs. 6A and 6B (which show that after
`each slice is selected and downloaded, the process repeats)”.
`POR at 37-39, 48-56; Sur-reply at 16, 18-20.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`4 of 40
`
`
`
`GOOGLE’S EXPERT, DR. POLISH, CONFIRMED HIS RELIANCE ON BOTH FIGS. 6A AND 6B OF
`CARMEL AS DISCLOSING SUCCESSIVE INDIVIDUAL SLICE REQUESTS BY SERIAL ID
`
`• Dr. Polish: As in the Petition, Dr. Polish maintained that both Figures 6A and 6B
`represented pulls. EX1002 ¶ 176: “Figs. 6A and 6B … show that after each slice is
`selected and downloaded, the process repeats.”
`
`• EX1002 ¶ 182: Similarly characterizing both Figs. 6A and 6B and showing them in a
`side-by-side illustration to highlight their similarity and argue the point.
`
`• Asked to describe the difference, Dr. Polish stated: “So the difference is 6B has a step
`in there to choose the level and to determine link rate.” EX2006-102:5-17 (question)-
`104:5-18 (answer).
`
`• Note – the Petition and its expert support were presented on the basis that both
`Figs. 6A and 6B were directed to “classic ‘client pull’”. Pet. at 38.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`POR at 32, 34; Sur-reply at 16.
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`5 of 40
`
`
`
`CARMEL DISCLOSES THE SERVER PUSHING SUCCESSIVE ELEMENTS FROM A
`SELECTED STARTING SLICE
`
`• Both Figs. 6A and 6B show only “HTTP FROM SERVER”.
`
`• Nothing anywhere in Carmel addresses any specific HTTP interactions
`between client and server.
`
`• HTTP 1.1, referenced in col. 2 of Carmel, added the ability for the server to
`push successive data elements in response to a single initiating request.
`EX2002 (Hoarty Decl.) ¶ 54 (“chunked transfer encoding”).
`
`POR at 26-27, 51-56; Sur-reply at 10-15.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`6 of 40
`
`
`
`CARMEL DISCLOSURES
`
`• Textual disclosure concerning Fig. 6A is in col. 10: “Responsive to a user input, client 30
`selects an appropriate starting slice and begins to download and decode (decompress)
`files 42, 44, 46, etc.”
`
`• GOOGLE ITSELF (Pet. at 29-30) tells us what “download” means!
`
`• A POSITA would understand that the client “downloading” the specified slice of
`data stream 40 involves “sending, by the server system,” the specified slice of
`data stream 40. (Polish, ¶¶ 139-140.) A POSITA understands that the term
`“downloading” means receiving a file on one machine (such as a remote
`personal computer) that has been sent from another machine (such as a
`server) via a communications means, such as over the Internet. (Id.)
`
`• No inference here whatsoever that “begins to download … files 42, 44, 46, etc.” implies
`that the server can send the files only responsive to successive individual requests for
`“file 42”, “file 44”, “file 46”, etc.
`
`POR at 28-29, 53-54.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`7 of 40
`
`
`
`CARMEL DISCLOSURES
`
`• Textual disclosure concerning Fig. 6B is at the bottom of col. 10, going over
`into col. 11: “Responsive to the selection, server 36 begins to transmit data
`slices at the chosen quality level.”
`
`• Nothing here remotely disclosing that this “transmission” is in response to
`individual requests for the slices by the serial IDs.
`
`• NO SUCH TEACHINGS ANYWHERE IN CARMEL.
`
`POR at 29-30, 32-33, 38, 52-55.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`8 of 40
`
`
`
`EVERY POINT SUPPORTED BY PO’S EXPERT MR. HOARTY
`
`• Hoarty (EX2002) addresses principles of operation of Carmel at ¶¶ 61-69.
`Quote –
`
`“I disagree with these views of Carmel expressed in the Petition and by
`Dr. Polish. A POSITA would not understand Carmel to disclose an
`individual request (pull) form of streaming. To the contrary, as I have
`explained, a POSITA would understand Carmel as disclosing that the
`server pushes successive stream slices from a designated starting
`slice.” (EX2002 ¶ 62).
`
`• Mr. Hoarty then specifically addresses limitations at issue: 1[b] (p36), 1[f]
`(p37), 1[f][i] (p39), i[f][iii] (p42), and 1[f][iv] (p43).
`POR at 26-27, 33-35, 37, 48-49, 51-53; Sur-reply at 9, 11, 6; Paper 28.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`9 of 40
`
`
`
`REPLY AT 12: “EACH FILE MUST BE INDIVIDUALLY REQUESTED—SOMETHING PO’S
`EXPERT ADMITS”
`
`UNTRUE. Look at the questions that were put:
`
`• The actual questions were limited by their terms to a request for a specific file.
`
`• EX1101:65:16-19: “Q. Okay. So if we -- excluding scripting, okay, so let's take
`a system where we're not gonna be using a script. We are using a request for
`a file of data.”
`
`• EX1101-66:1-18: “Q. So I send a request for File A … Would the server send
`me, based on that scenario, File B?”
`To argue based on this that Mr. Hoarty somehow confirmed or
`“admitted” that ALL HTTP requests MUST BE for INDIVIDUAL
`FILES is FALSE.
`
`Sur-reply 11-13.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`10 of 40
`
`
`
`PETITION FAILS TO ACKNOWLEDGE REALITY OF WHERE CARMEL FALLS SHORT
`
`Shortcomings: 1[b], 1[e], 1[f][i], 1[f][iii], 1[f][iv]
`▪ 1[b]: “supplying, at the server system, media data elements representing the program, each media data
`element comprising a digitally encoded portion of the program and having a playback rate”. EX1001-
`16:43-46.
`
`▪ 1[e]: “receiving requests at the server system via one or more data connections over the Internet, for
`one or more of the media data elements stored in the data structure, each received request specifying
`one or more serial identifiers of the requested one or more media data elements, each received
`request originating from a requesting user system of the one or more user systems”. EX1001-16:52-58.
`
`▪ 1[f][i]: “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”. EX1001-16:64-67.
`
`▪ 1[f][iii]: “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”.
`EX1001-17:4-7.
`
`▪ 1[f][iv]: “all of the media data elements that are sent by the server system to the one or more user
`systems are sent in response to the requests”. EX1001-17:8-10.
`
`POR at 36-55.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`11 of 40
`
`
`
`LIM. 1[b] {f/k/a c}: (supplying, at the server system, media data
`elements)
`
`• Google: “supplying at the server system” means “creating, at the server system”
`(Pet. at 16). Cites Dr. Polish, EX1002 ¶ 101.
`
`• Carmel – “creates” the slice on computer 34, not server 36.
`
`• Google attempted to address this, but only by a limiting construction:
`
`o All the Petition said was in ¶ 101 of Dr. Polish’s Decl. (EX1002): “ ‘Creating’
`media data elements is certainly one way to ‘supply’ media data elements.”
`
`o Begs the question of where they are created, and what is creating it.
`
`• This is an issue of Google’s own making, due to its extremely contrived claim
`construction.
`
`POR at 36-37.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`12 of 40
`
`
`
`(Cont’d) LIM. 1[b] {f/k/a c}: (supplying, at the server system, media
`data elements)
`
`In Reply – Google asserts for the first time that “server system”
`comprises both computer 34 and server 36.
`
`• But this new argument on Reply, based on aggregation of
`components, is also contrived.
`• Nothing else in the claim even could relate to anything performed
`by computer 34 in Carmel.
`• There is nothing in the claim to suggest that some kind of server
`“system” extends beyond the server itself.
`
`POR at 36-37; Sur-reply at 20.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`13 of 40
`
`
`
`Re: Lim. 1[b]
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`Pet. 16-19
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`14 of 40
`
`
`
`Re: Lim. 1[b]
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`Pet. 16-19
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`15 of 40
`
`
`
`LIM. 1[e] {f/k/a f}
`
`“receiving requests at the server system via one or more data connections over the
`Internet, for one or more of the media data elements stored in the data structure,
`each received request specifying one or more serial identifiers of the requested
`one or more media data elements, each received request originating from a
`requesting user system of the one or more user systems”
`
`Petition’s theory (Pet. at 24-26) is unmistakably
`based on assertion that Carmel teaches successive
`element individual pull, and nothing else.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`POR at 38-39.
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`16 of 40
`
`
`
`(Cont’d) LIM. 1[e] {f/k/a f}
`
`“receiving requests at the server system via one or more data connections over the
`Internet, for one or more of the media data elements stored in the data structure, each
`received request specifying one or more serial identifiers of the requested one or more
`media data elements, each received request originating from a requesting user system
`of the one or more user systems”
`
`Petition at 24, beginning four lines down:
`o “The user of client device 30 can ‘indicate at which slice of data stream 40 to begin downloading.’
`(Carmel, 10:44-45.)”
`
`o “‘Responsive to [this] user input, client 30 selects an appropriate starting slice and begins to
`download and decode (decompress) files 42, 44, 46, etc.’”
`
`o “Carmel clearly teaches the client devices submit requests for multimedia data, and the server
`system receives those requests.”
`
`o In support – Cites both Figs. 6A and 6B (Pet. at 26-29).
`
`POR at 38-39.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`17 of 40
`
`
`
`(Cont’d) LIM. 1[e] {f/k/a f}: receiving requests … for one or more of the media data
`elements … each received request specifying one or more serial identifiers of the
`requested one or more media data elements …
`
`• Pet. at 25 (trying to show “requests”): “A POSITA would understand the request from
`the client 30 specifies the slice by reference to the slice’s serial identifier. (Polish,
`¶125.) Carmel discloses the client request for a particular data slice 42, 44, 46, etc.
`specifies the slice by referencing the corresponding slice index.”
`
`• Pet. at 26 (bottom): “And in both options [referring to starting at the latest slice or at
`an earlier slice], Carmel Figure 6A confirms this process is repeated for each slice.”
`
`Petition’s characterization as repeated individual requests
`by serial ID is clear and unmistakable.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`POR at 39.
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`18 of 40
`
`
`
`Re: Lim. 1[e]
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`Pet. 23-29
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`19 of 40
`
`
`
`Re: Lim. 1[e]
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`Pet. 23-29
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`20 of 40
`
`
`
`Re: Lim. 1[e]
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`Pet. 23-29
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`21 of 40
`
`
`
`(Cont’d) LIM. 1[e] {f/k/a f}: receiving requests … for one or more of the media data
`elements … each received request specifying one or more serial identifiers of the
`requested one or more media data elements …
`
`In Reply only (at 20-21) – Google raises claim construction
`and then argues that Carmel does not meet the
`construction.
`
`But even this new Reply argument relies 100% on claim
`construction.
`
`POR at 12-13, 39; Sur-reply at 4-5.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`22 of 40
`
`
`
`LIM. 1[f][i] {f/k/a h}: (connection data rate limitation)
`
`Petition argues express disclosure, or at least implicit
`disclosure of this limitation (data rate of the data
`connection), from within the four corners of Carmel
`(Pet. 30-34).
`
`Relies on three alternative arguments …
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`23 of 40
`
`
`
`LIM. 1[f][i] {f/k/a h}: Petition’s FIRST alternative on connection data rate
`argument
`
`• First (Pet. at 31), “data rate should be generally equal to or faster than the
`[playback rate]”.
`
`o “data rate” of what? Limitation says “of the data connection” – Carmel
`fails to disclose this.
`▪ data connection must sustain its capability over the duration of
`playback. Not an instantaneous rate as clearly posited in prior PTAB
`decision. EX2011 at 20 (’141 Patent Remand Decision) (distinguishing
`any “overall rate” for purposes of the ’141 claims there at issue).
`
`• Further (Pet. at 32), Google relies on the upload process – clearly
`misplaced.
`
`POR at 43-45.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`24 of 40
`
`
`
`LIM. 1[f][i] {f/k/a h}: Petition’s SECOND alternative on connection data
`rate argument
`
`• Second (Pet. at 32), Google points to changing the elements
`themselves during transmission.
`
`• This is not addressing the data rate of the data connection, but
`rather downshifting what is sent over the connection.
`
`POR at 46-47.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`25 of 40
`
`
`
`LIM. 1[f][i] {f/k/a h}: Petition’s THIRD alternative on connection data rate argument
`
`• Third, Google argues the “overall” connection by aggregating links over
`connections that have lower data rates.
`
`o This is slice-wise alternation, sending slices alternately on different links.
`EX1003-2:60-63.
`
`o This concedes that each slice is being sent slower than the playback rate,
`and is not consistent with the ’824/’636 patent disclosures.
`
`o Carmel only says that the aggregate rate is “generally sufficient” (EX1003-
`2:67), which in the case of Carmel’s push would be equal to the playback
`rate.
`
`▪ Carmel never says that the aggregate is faster than the playback rate.
`
`o Carmel repeats seven times (specifically for download process) merely that
`the data rate must be “generally equal to” the playback rate.
`
`POR at 47-48.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`26 of 40
`
`
`
`LIM. 1[f][i] {f/k/a h}: (connection data rate limitation)
`
`• Limitation 1[f][i] (rate limitation) is presented in the Petition strictly as
`a question of what is disclosed. But,
`o Internet connections vary all over the place.
`
`o Claimed data rate “of the data connection” not met by a transient
`spike over the connection.
`o Nor (per Reply at 22) is requisite connection inconsistent with
`transient congestion. The whole point of this patent is that the
`internet is characterized by recurring congestion.
`
`POR at 42; Sur-reply at 5-7.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`27 of 40
`
`
`
`Re: Lim. 1[f](i)
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`Pet. 30-34
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`28 of 40
`
`
`
`Re: Lim. 1[f](i)
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`Pet. 30-34
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`29 of 40
`
`
`
`LIM. 1[f][iii] (f/k/a j): (no server dependency on record of last element sent)
`
`• Petition clearly stakes its ground: “the client 30 is responsible for
`selecting the data slice that is to be transmitted. The server system in
`Carmel does not maintain a record of the last data slice sent to client 30.”
`(Pet. at 37).
`
`• Again (Pet. at 38-40) tries to argue Carmel’s Figs. 6A and 6B (making no
`material distinction, a point that Dr. Polish confirmed). EX2006:105:13-
`106:8.
`• But again, in fact, nothing in Carmel discloses successive individual slice
`requests.
`
`POR at 49-51.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`30 of 40
`
`
`
`(Cont’d) LIM. 1[f][iii] (f/k/a j): (no server dependency on record of last element sent)
`
`Reexam ’141 decision, EX2017-9
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`Paper 28.
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`31 of 40
`
`
`
`(Cont’d) LIM. 1[f][iii] (f/k/a j): (no server dependency on record of last
`element sent)
`
`Chunked encoding, EX2005-21:
`
`POR at 26, 49-50.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`32 of 40
`
`
`
`(Cont’d) LIM. 1[f][iii] (f/k/a j): (no server dependency on record of last
`element sent)
`
`Google’s Reply on Chunked encoding:
`
`• Google, arguing that HTTP must be for files, cites Swaminathan.
`
`• But Polish conceded that Swaminathan was referring to chunking
`within the fragments, not the fragments themselves being chunks.
`EX2016-28:24-30:5.
`
`Sur-reply at 13.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`33 of 40
`
`
`
`(Cont’d) LIM. 1[f][iii] (f/k/a j): (no server dep. on record of last element sent)
`
`Reply-18: “Mr. Hoarty agree[s] that when the slices are stored as individual files,
`separate HTTP requests must be sent for each file”
`
`UNFOUNDED.
`
`•
`
`•
`
`•
`
`The actual question was limited by its terms to a request for a specific file.
`
`“Q. Okay. So if we -- excluding scripting, okay, so let's take a system where
`we're not gonna be using a script. We are using a request for a file of data.”
`EX1101:65:16-19.
`
`To argue based on this that Hoarty somehow confirmed that all HTTP
`requests must be for individual files is FALSE.
`
`POR at 49-50; EX2002 ¶ 84-86.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`34 of 40
`
`
`
`(Cont’d) Lim. 1[f][iii] (f/k/a j): (no server dependency on record of last element sent)
`
`Google Reply presents a FLIP FLOP on Carmel’s Fig. 6B embodiment
`
`• The Petition argues Figs. 6A and 6B in the same breath, throughout.
`
`• On Reply, Google tries to argue for the first time that Carmel’s Fig. 6A is materially different from
`Fig. 6B.
`
`o Reply at 17-18, arguing original Israeli filing, without multi-level embodiment.
`
`o But - dependent claim structure makes sense only if mechanism consistent with single-level
`claims.
`
`o Carmel’s disclosure of multi-level is introduced as “Alternatively or additionally.” EX1003-7:44-
`49. “Additionally” means simply adding multi-level capability to the base embodiment.
`
`o Dr. Polish conceded the same, as to the difference between 6A and 6B. So the difference is 6B
`has a step in there to choose the level and to determine link rate.” EX2006-102:5-17 (question)-
`104:5-18 (answer).
`
`POR at 30-31, 34; Sur-reply at 19-20.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`35 of 40
`
`
`
`(Cont’d) LIM. 1[f][iii] (a/k/a j): (no server dependency on record of last element sent)
`
`•
`
`“Mutatis mutandis” – EX1003-13:7-10 and EX1003-13:30-35.
`
`o Raised in the Petition at 32, but simply to seek to apply the timing of delivery in upload process equally to
`download process.
`
`• Google’s citation to EX1003-13:30-35:
`
`o “it will be understood that similar methods are applicable, mutatis mutandis, to the method of downloading
`the files from server 36 to clients 30”.
`
`o Allegedly (according to Google) “confirming techniques used for upload are applicable to download in Fig.
`6A” (Reply at 11).
`
`•
`
`Yet, Google doesn’t dispute that the upload is a push. Isn’t this inconsistent on its face?
`
`o Google’s expedient, in its Reply – on top of transposing Carmel’s 34→36 process onto 36→30, would now
`also interchange client 30 and server 36.
`
`o Magically turns “push” into “pull.”
`
`o There is no other way to read the Reply at 24, than to be proposing such a role reversal.
`
`THIS DOUBLE INTERCHANGE PROPOSED IN THE REPLY IS A RESULT-ORIENTED AFTERTHOUGHT,
`NOT “PRINTED PUBLICATION” DISCLOSURE.
`
`Sur-reply at 1-2, 9, 25.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`36 of 40
`
`
`
`Re: Lim. 1[f](iii)
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`Pet. 37-40
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`37 of 40
`
`
`
`LIM. 1[f][iv] (f/k/a k): (all elements sent requested by ID)
`
`The ENTIRE ARGUMENT on this is at pages 40-41 of the Petition, and it
`unmistakably argues Carmel only as teaching successive individual slice
`requests by the client, each by serial ID:
`
`“Server 36 cannot send data slices without the client’s input and selection. Not only is this
`confirmed by Figs. 6A and 6B (which show that after each slice is selected and downloaded,
`the process repeats), a POSITA would understand from the overall disclosure in Carmel that
`the clients 30 control which slices are requested from (and therefore sent by) the server
`system.” (Pet. at 40)
`
`“Likewise, for Carmel’s lag recovery … A POSITA would understand that since the client 30 is
`changing the quality level of the slices, that the client 30 is controlling which data slices (and
`at what quality) are being requested and sent by the server. (Polish, ¶176.) Accordingly, all
`data slices that are sent by server 36 “are sent in response to” client requests for such data
`slices. (Id.)” (Pet. at 41)
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`38 of 40
`
`
`
`Re: Lim. 1[f](iv)
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`Pet. 40-41
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`39 of 40
`
`
`
`GROUNDS 2 AND 3
`
`Only two contentions:
`
`• Ravi, but only as to 1[f][iii] (a/k/a limitation i) – as fast as
`connection allows.
`
`• Narrayan, but only as to preamble.
`
`• Neither matters.
`
`POR at 56-59.
`
`WAG DEMONSTRATIVE EXHIBIT – NOT EVIDENCE – IPR2022-01412, -01413
`
`WAG, Exhibit 2018
`Google LLC v. WAG Acquisition, LLC, IPR2022-01413
`40 of 40
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
