`571-272-7822
`
` Entered: March 23, 2023
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`___________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`GOOGLE LLC,
`Petitioner,
`
`v.
`
`WAG ACQUISITION, L.L.C.,
`Patent Owner.
`____________
`
`IPR2022-01413
`Patent 9,762,636 B2
`____________
`
`
`
`Before HUBERT C. LORIN, JOHN A. HUDALLA, and
`STEVEN M. AMUNDSON, Administrative Patent Judges.
`
`LORIN, Administrative Patent Judge.
`
`
`
`
`DECISION
`Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`
`
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`A. Background
`
`
`I. INTRODUCTION
`
`Google LLC (“Petitioner”) filed a Petition (Paper 1, “Pet.”) requesting
`inter partes review of claims 1–12 of U.S. Patent No. 9,762,636 B2
`(Ex. 1001, “the ’636 patent”). WAG Acquisition, L.L.C. (“Patent Owner”)
`filed a Preliminary Response. Paper 6 (“Prelim. Resp.”).
`We have jurisdiction under 35 U.S.C. § 6.
`Upon consideration of the arguments and evidence presented by
`Petitioner, we are persuaded that Petitioner has demonstrated, under
`35 U.S.C. § 314(a), a reasonable likelihood that it would prevail in showing
`the unpatentability of at least one challenged claim.
`For the reasons stated below, we institute inter partes review as to
`challenged claims 1–12 of the ’636 patent.
`
`B. Related Proceedings
`
`Petitioner indicates that the ’636 patent is asserted in pending district
`court litigation styled WAG Acquisition, L.L.C. v. Google LLC, No. 6:21-cv-
`00816-ADA (W.D. Tex.). Pet. 1; see also Paper 3 (Patent Owner’s
`Mandatory Notices), 2.
`Petitioner indicates that the ’636 patent is also the subject to the
`following other pending district court litigations:
`• WAG Acquisition, LLC v. The Walt Disney Company, No. 2:21-cv-
`08230 (C.D. Cal., filed Oct. 18, 2021); and,
`
`
`
`• WAG Acquisition, LLC v. Amazon.com, Inc., No. 6:21-cv-00815
`(W.D. Tex., filed Aug. 6, 2021).
`
`Pet. 1; Paper 3, 2.
`
`2
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`Petitioner also makes us aware that the ’636 patent is the subject of
`pending Office proceeding IPR2022-01227 (P.T.A.B.) (filed July 13, 2022).
`Pet. 1–2. Patent Owner makes us aware that the ’636 patent is also subject
`to the pending Office proceeding IPR2022-01433 (P.T.A.B.) (filed Aug. 23,
`2022). Paper 3, 4–5.
`Patent Owner makes us aware of other district court litigations
`involving U.S. Patent Nos. 6,766,376, 8,122,141, 8,327,011, 8,185,611,
`8,364,839, 9,742,824, and 9,729,594 related to the ’636 patent.
`Paper 3, 2–4. Patent Owner makes us aware of other Office proceedings
`involving U.S. Patent Nos. 8,122,141, 8,327,011, 8,185,611, 8,364,839,
`9,729,594, and 9,742,824, related to the ’636 patent. Id. at 4–8.
`
`C. Real Party in Interest
`
`Petitioner identifies Google LLC and YouTube LLC as real parties in
`interest. Pet. 1. According to Patent Owner, “WAG ACQUISITION, L.L.C.
`is the real party in interest.” Paper 3, 2.
`D. The ’636 Patent (Ex. 1001)
`
`1. Disclosure
`
`The ’636 patent, titled “Streaming Media Delivery System,” relates
`“to systems and methods for delivering streaming media, such as audio and
`video, on the Internet.” Ex. 1001, code (54), 1:52–55.
`The ’636 patent describes problems with prior-art streaming
`technologies, where “users viewing or listening to streaming content over
`Internet connections often encounter interruptions, due to the frequency of
`unanticipated transmission delays and losses that are inherent in many
`Internet protocols.” Id. at 2:34–38. The patent describes prior-art methods
`
`3
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`of addressing this, involving a “pre-buffering technique to store up enough
`audio or video data in the user’s computer so that it can play the audio or
`video with a minimum of dropouts.” Id. at 2:42–45. After several seconds
`waiting for playback to begin, the “audio or video data is delivered from the
`source at the rate it is to be played out.” Id. at 2:63–65. Playback would
`continue, but could still be interrupted by network interruptions. Id. at 3:5–
`41.
`
`The ’636 patent addresses this by, for example, “sending initial
`streaming media elements to the user system at a sending rate more rapid
`than the playback rate, to fill the user buffer,” and then continuing sending
`media elements “at about the playback rate.” Id. at 3:60–64. Figure 1,
`reproduced below, shows a block diagram of the elements of the streaming
`media buffering system of the ’636 patent. Id. at 4:23–25.
`
`4
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`
`
`Figure 1 shows streaming server 12, Internet 10, server buffer 14,
`buffer manager 16, and user computer 18, with buffer 20.
`Id. at 6:30-52.
`When a user connects to the server 12, the server transmits
`audio/video data, as sequential data elements, from the server’s buffer 14 to
`the user buffer 20, at a higher-than-playback rate. Id. at 9:36–39. The
`“media begins to play on the user computer 18 as soon as the user
`connection is made to the audio server 12 and a minimal amount of data
`elements have been received and stored in the user’s buffer 20.” Id. at 9:40–
`45.
`
`5
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`Additionally, the patent describes the user playback device
`“maintaining a record of the identifier of the last sequential media data
`element that has been received by said player,” and then “requesting
`transmission of the next sequential media data elements following said last
`sequential media data element.” Id. at 4:7–11. The patent also describes
`that:
`
`If the interruptions are so severe as to deplete the user’s buffer
`and stop the play out, the media player can quickly recover as
`well, by beginning to play out again without waiting to first build
`up the buffer, as soon as the media player begins to receive media
`data elements.
`
`Id. at 6:25–29. The “source server 12 sends the media as sequential data
`elements at a rate dependent on the quality of the connection with each user
`computer 18.” Id. at 11:13–16.
`Initially, the user buffer manager 22 requests the server 12 send media
`data elements, to start playback. Id. at 9:46–47. The server sends elements,
`at a rate “higher than the playback rate,” until the server’s buffer has been
`sent. Id. at 9:48–53. A “feedback manager may be associated with user
`computer 18, including means for sending to the source server the serial
`number of the last data element received, or for requesting more data.” Id. at
`10:50–53.
`2. Claims 1, 3, 4, and 6
`
`Petitioner challenges claims 1–12. Pet. 1. Claims 1, 5, and 9 are
`independent.
`Claim 1 is the independent claim from which claims 2–4 depend. It is
`reproduced below. Bracketing is added to assist in referring to the claim
`elements.
`
`6
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`[preamble]1 A method for distributing a live audio or video
`1.
`program over the Internet from a server system to a plurality of user
`systems, the method comprising:
`1[a] 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[b] upon receipt of the stream by the server system,
`1[b(i)] 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,
`1[b(ii)] serially identifying the media data elements, said serial
`identification indicating a time sequence of the media data
`elements, and
`1[b(iii)] storing the media data elements in a data structure
`under the control of the server system;
`1[c] 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,
`1[c(i)] each received request specifying one or more serial identifiers
`of the requested one or more media data elements,
`1[c(ii)] each received request originating from a requesting user system
`of a plurality of user systems; and
`1[d] responsive to the requests, sending, by the server system, the one
`or more media data elements having the one or more specified serial
`identifiers, to the requesting user systems corresponding to the
`requests; wherein
`1[d(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;
`
`
`1 Petitioner’s designations to reference the elements of claim 1 are set forth
`in brackets. Pet. 13–47. Herein we refer to the elements of claim 1 using
`Petitioner’s designations.
`
`7
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`1[d(ii)] each sending is at a transmission rate as fast as the data
`connection between the server system and each requesting
`user system allows;
`1[d(iii)] the one or more media data elements sent are selected
`without depending on the server system maintaining a record
`of the last media data element sent to the requesting user
`systems;
`1[d(iv)] all of the media data elements that are sent by the server
`system to the plurality of user systems are sent in response to
`the requests; and
`1[d(v)] all of the media data elements that are sent by the server
`system to the requesting user systems are sent from the data
`structure under the control of the server system as the media
`data elements were first stored therein.
`Ex. 1001, 16:28–17:8.
`E. Asserted References and Testimonial Evidence
`
`Petitioner relies on the following references:
`
`Reference
`
`U.S. Patent No. 6,389,473 B1, issued May 14,
`2002
`U.S. Patent No. 6,292,834 B1, issued Sept. 18,
`2001
`U.S. Patent No. 6,008,853, issued Dec. 28,
`1999
`
`Ex. No.
`
`1003
`
`1004
`
`Name
`
`Carmel
`
`Ravi
`
`Narayan
`
`Petitioner also relies on the Declaration of Nathaniel Polish, Ph.D.
`(Ex. 1002, “Polish Decl.”) as support for the various contentions.
`F. Asserted Grounds
`
`1005
`
`Petitioner contends that claims 1–12 of the ’636 patent are
`unpatentable under the following grounds:
`
`
`
`8
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`Claim(s)
`Challenged
`1–12
`
`1–12
`
`1–12
`
`1–12
`
`Ground
`
`I
`
`II
`
`III
`
`IV
`
`Pet. 4.
`
`
`
`35 U.S.C. §
`
`Reference(s)/Basis
`
`103(a)2
`
`Carmel
`
`103(a)
`
`103(a)
`
`103(a)
`
`Carmel, Narayan
`
`Carmel, Ravi
`
`Carmel, Narayan, Ravi
`
`II. ANALYSIS
`A. Principles of Law for Patentability
`
`A patent claim is unpatentable under 35 U.S.C. § 103(a) if the
`differences between the claimed subject matter and the prior art are such that
`the subject matter, as a whole, “would have been obvious at the time the
`invention was made to a person having ordinary skill in the art to which said
`subject matter pertains.” KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406
`(2007). The question of obviousness is resolved on the basis of underlying
`factual determinations including: (1) the scope and content of the prior art;
`(2) any differences between the claimed subject matter and the prior art;
`(3) the level of ordinary skill in the art; and (4) when in evidence, objective
`
`
`2 The Leahy-Smith America Invents Act, Pub. L. No. 112–29, 125 Stat. 284
`(2011) (“AIA”), amended 35 U.S.C. §§ 102 and 103. Because the
`challenged claims of the ’636 patent have an effective filing date before the
`effective date of the applicable AIA amendments, we refer to the pre-AIA
`version of 35 U.S.C. §§ 102 and 103 throughout this Decision.
`9
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`evidence of nonobviousness. Graham v. John Deere Co., 383 U.S. 1, 17–18
`(1966).
`“In an [inter partes review], the petitioner has the burden from the
`onset to show with particularity why the patent it challenges is
`unpatentable.” Harmonic Inc. v. Avid Tech., Inc., 815 F.3d 1356, 1363 (Fed.
`Cir. 2016) (citing 35 U.S.C. § 312(a)(3) (requiring inter partes review
`petitions to identify “with particularity . . . the evidence that supports the
`grounds for the challenge to each claim”)). This burden of persuasion does
`not shift to Patent Owner, except in limited circumstances not present here.
`See Dynamic Drinkware, LLC v. Nat’l Graphics, Inc., 800 F.3d 1375, 1378
`(Fed. Cir. 2015) (discussing the burden of proof in inter partes review).
`B. Level of Ordinary Skill in the Art
`
`Petitioner contends a person of ordinary skill in the art
`as of the alleged priority date would have possessed at least a
`bachelor’s degree in computer science or an equivalent field
`requiring learning computation principles, and two years of work
`experience
`in networking or streaming media systems,
`particularly audio and video, over the Internet. Additional
`education could compensate for less practical experience.
`Conversely, additional practical experience could compensate
`for less education.
`
`Pet. 8–9 (citing Polish Decl. ¶¶ 21–23).
`
`Patent Owner “does not dispute [Petitioner’s] characterization of a”
`person of ordinary skill in the art at this stage of the proceeding. Prelim.
`Resp. 14.
`
`Petitioner’s proposed definition of a person of ordinary skill in the art
`appears reasonable, and we adopt that definition for our analysis in this
`decision.
`
`10
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`Moreover, Petitioner’s proposed definition appears to be consistent
`with the level of skill reflected by the prior art of record. Okajima v.
`Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001); In re GPAC Inc., 57 F.3d
`1573, 1579 (Fed. Cir. 1995); In re Oelrich, 579 F.2d 86, 91 (CCPA 1978).
`C. Claim Construction
`
`“[Claims] of a patent . . . shall be construed using the same claim
`construction standard that would be used to construe the [claims] in a civil
`action under 35 U.S.C. [§] 282(b), including construing the [claims] in
`accordance with the ordinary and customary meaning of such claim[s] as
`[would have been] understood by one of ordinary skill in the art and the
`prosecution history pertaining to the patent.” 37 C.F.R. § 42.100 (2022); see
`also Phillips v. AWH Corp., 415 F.3d 1303, 1312–14 (Fed. Cir. 2005).
`Petitioner provides a table of “[c]laim terms [which] have been
`proposed for construction by Petitioner.” Pet. 9–10. But it “does not
`presently contend that any term requires express construction.” Id. at 9.
` Patent Owner indicates, inter alia, that it “disagrees with the
`constructions of certain terms Petitioner has proffered.” Prelim. Resp. 15
`(citing Pet. 10). According to Patent Owner, “the claim terms are entitled to
`their plain and ordinary meaning.” Id. However, Patent Owner does not
`presently contend that any claim term requires express construction. See
`generally Prelim. Resp. 14–19.
`We determine that express construction of any term is not required at
`this stage. To the extent the meaning of any other term requires discussion,
`we provide it in our analysis of the patentability challenges. In that regard,
`only those terms that are in controversy need to be construed, and only to the
`
`11
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`extent necessary to resolve the controversy. Vivid Techs., Inc. v. Am. Sci. &
`Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).
`Patent Owner discusses findings in earlier proceedings related to U.S.
`Patent 8,122,141. See Prelim. Resp. 15–19; Ex. 1061. This is prompted by
`Patent Owner’s belief that the “Petition suggests that claim constructions
`and factual findings from earlier Board decisions concerning the ’141 patent
`are applicable here.” Id. at 15 (citing “e.g., Petition at 34 n.4, 36 n.5”).
`However, as Patent Owner acknowledges, “[t]he Petition advances no legal
`arguments as to why findings from earlier proceedings against another
`patent should be applicable here.” Id. Accordingly, we find it unnecessary
`to address claim constructions and factual findings from earlier Board
`decisions concerning the ’141 patent at this stage.
`D. Overview of the Prior Art References
`
`1. Carmel (Ex. 1003)
`
`Carmel describes a method for streaming live or prerecorded media
`from a server to multiple client computers over the Internet. Ex. 1003, 2:1–
`21. Clients connect to a server to receive a multimedia sequence,
`“substantially in real time.” Id. at 7:4–5. Figure 3A of Carmel is reproduced
`below.
`
`12
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`
`
`Figure 3A is a block diagram that schematically illustrates a data
`structure of a stream of broadcast data 40, typically corresponding to a
`multimedia data sequence. Id. at 7:18–22.
`Data stream 40 comprises a series of data slices 42, 44, 46, 48, etc.,
`with each slice containing a segment of video and/or audio data that
`corresponds to a respective, successive time interval T1, T2, T3, etc.
`Ex. 1003, 7:22–25. Each slice is stored as a corresponding file with a
`running slice index 1, 2, 3, . . . N, and perhaps also a time stamp that
`indicates a real time at which the data in the file were recorded or an elapsed
`time relative to the beginning of the stream. Id. at 7:27–32. An index file
`that comprises a slice ID is uploaded to a server, with the slice ID indicating
`the index of the file in the data stream that was most recently uploaded.
`Id. at 7:59–64. Each time a new file is uploaded, the slide ID is updated.
`Id. at 7:65–66.
`When a client computer connects to the stream, the client computer
`downloads and analyzes the index file to identify at what point in the stream
`to begin, to receive the data stream from that point in substantially real time
`as it is transmitted. Ex. 1003, 8:1–7. For example, a user interface graphic
`
`13
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`“slider” may be displayed to computer users, allowing individual users to
`select the starting point of the streamed media. Id. at 8:17–31.
`2. Ravi (Ex. 1004)
`
`Ravi, titled “Dynamic Bandwidth Selection for Efficient Transmission
`of Multimedia Streams in a Computer Network,” relates “to the efficient and
`reliable delivery of multimedia streams over a diverse computer network
`with dynamically variable bandwidth capacity.” Ex. 1004, code (54),
`1:56–60. Ravi seeks “efficient transmission of multimedia streams from a
`server to a client computer over a diverse computer network including local
`area networks (LANs) and wide area networks (WANs) such as the
`internet.” Id. at 3:2–6. The “client computer includes a playout buffer, and
`the transmission rate is dynamically matched to the available bandwidth
`capacity of the network connection between the server and the client
`computer.” Id. at 3:11–15. The “performance bottleneck is the bandwidth
`capacity of the network connection.” Id. at 7:6–10.
`2. Narayan (Ex. 1005)
`
`Narayan, titled “Sub-Frame Decoder with Area Dependent Update
`Rate for Digital Camcorder Transmission Standard,” relates to “encoded
`video image decoding and especially software only decoding on a personal
`computer.” Ex. 1005, code (54), 1:10–12. Narayan “employs a digital
`camcorder to generate the stream of video image data. This is transmitted to
`a personal computer, preferably a notebook computer, for decoding and
`display.” Id. at 1:66–2:2.
`
`14
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`E. Ground 1—Obviousness over Carmel Alone
`
`Petitioner challenges claims 1–12 as unpatentable under 35 U.S.C.
`§ 103(a) over Carmel. Pet. 13–54.
`1. Claim 1
`
`Petitioner contends that Carmel teaches or renders obvious all that is
`claimed. See Pet. 13–47.
`We observe that Patent Owner has not responded to Petitioner’s
`challenge as to the preamble and limitations 1[a]–1[d] and 1[d(v)] with any
`particularity at this stage of the proceeding. See generally Prelim. Resp.
`19–36. As to these limitations, we have reviewed the evidence Petitioner
`has presented, briefly discussed below with respect to each limitation, and
`based on that evidence we determine that at this stage Petitioner sufficiently
`shows on this record that Carmel teaches the preamble and limitations 1[a]–
`1[d] and 1[d(v)] as claimed.
`Our discussion of limitations 1[d(i)]–1[d(iv)] addresses Patent
`Owner’s specific arguments.
`1.
`[preamble] A method for distributing a live audio or
`video program over the Internet from a server system to a
`plurality of user systems, the method comprising:
`Petitioner contends that Carmel teaches the preamble. Pet. 13–14
`(citing Ex. 1003, 2:1–4, Abstract).
`Petitioner reproduces Figure 2 of Carmel (reproduced below) and
`explains that “computer 34 ‘receives audiovisual input from input device
`22,’ where input device 22 may be a video camera (to capture video and/or
`audio) or a microphone (to capture audio).” Pet. 14 (citing Polish Decl.
`
`15
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`¶ 95). Petitioner explains that Carmel teaches a system whereby computer
`34 is a transmitting computer which generates a “multimedia sequence.”
`Id. (citing Ex. 1003, 6:28-30, see also 6:26). According to Petitioner, a
`person of ordinary skill in the art would understand “‘multimedia’ refers to a
`broad array of communications, including live video or audio.” Id. (citing
`Ex. 1003, 6:32–35).
`
`In support of its contention that Carmel teaches distributing the live
`audio or video over the Internet, Petitioner quotes Carmel: “[computer 34,] a
`plurality of clients 30, and network server 36, all of which communicate
`over network 28, preferably using the well-known Internet Protocol (IP).”
`Pet. 14 (quoting Ex. 1003, 6:28–31, referring to Figure 2, reproduced
`below).
`
`
`Figure 2 is a schematic illustration of a computer system comprising a
`transmitting computer 34 that receives audiovisual input from device
`22, a plurality of clients 30, and a network server 36, all communicating
`with each other over a network 28. Ex. 1003, 6:24–35.
`In our view, at this stage, Petitioner sufficiently shows on this record
`
`that Carmel teaches the preamble as claimed.
`
`16
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`1[a] 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;
`Petitioner contends that Carmel teaches this step. Pet. 15–16.
`Petitioner points to input device 22 as the “live source” in Carmel’s
`system. Pet. 15 (referring to Figure 2, see supra). According to Petitioner, it
`“provides an ‘audiovisual input’ to the transmitting computer 34.” Id.
`(citing Ex. 1003, 6:32–35).
`Petitioner further explains that the “input devices 22 (live source) in
`Carmel’s system shares a ‘data connection’ with the server system [i.e.,
`transmitting computer 34 and server 36].” Pet. 16. “In Carmel’s
`embodiment illustrated in Figure 2, the ‘data connection’ is the
`communication wire connecting the input device(s) 22 to the computer 34.”
`Id. (citing Polish Decl. ¶ 98).
`As for the limitation “receiving at the server system a continuous
`digitally encoded stream for the audio or video program,” Petitioner
`contends that computer 34 receives such a stream from input device 22.
`Pet. 17 (citing Polish Decl. ¶ 99). That input device 22 transmits such a
`stream would have been obvious to a person of ordinary skill in the art,
`according to Petitioner, “[g]iven the state of the art and the common use of
`digital recording equipment.” Id. (citing Polish Decl. ¶ 100). As evidence
`of the state of the art, Petitioner cites, inter alia, video cameras “well known
`in the art that . . . could output video in digital format to a computer as by the
`mid-1990s, [such as] the DV (digital video) standard [that] was widely
`adopted by the camera and video industry.” Id. (citing e.g., Ex. 1021, 3;
`Polish Decl. ¶ 100).
`
`17
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`In our view, at this stage, Petitioner sufficiently shows on this record
`
`that Carmel teaches the “receiving” step as claimed.
`1[b] upon receipt of the stream by the server system,
`Petitioner reiterates its contention (see discussion with respect to
`
`limitation 1[a]) that Carmel teaches computer 34 (which is part of the server
`system) receiving an audiovisual input from input device 22. Pet. 18
`(quoting Ex. 1003, 6:32–33, 9:64–65 (“Broadcast data are then input to the
`computer, for example, from input devices 22”)). According to Petitioner,
`this teaching meets the limitation. Id.
`In our view, at this stage, Petitioner sufficiently shows on this record
`that Carmel teaches the limitation as claimed.
`1[b(i)] 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,
`Petitioner contends that Carmel teaches this step. Pet. 18–21.
`Petitioner contends that “Carmel teaches . . . the audiovisual data is
`
`input to the computer 34 from the input devices 22.” Pet. 19 (citing
`Ex. 1003, 7:19–21, 9:66–67). According to Petitioner, this shows Carmel
`teaches “supplying” audiovisual data “at the server system,” as claimed. Id.
`
`Petitioner explains that, after the input, “the data is compressed into
`data stream 40.” Pet. 19 (citing Ex. 1003, 7:19–21, 9:66–67). “This data
`stream 40 is ‘then “sliced” . . . into files 42, 44, 46, 48, etc., as shown in
`FIG. 3A.’” Id. (quoting Ex. 1003, 9:67–10:1). Petitioner reproduces
`Figure 3A of Carmel showing said slices. Id. (reproduced below and above
`in section II.D.1.).
`
`18
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`
`
`Figure 3A is a block diagram that schematically illustrates a data
`structure of a stream of broadcast data 40, typically corresponding to a
`multimedia data sequence. Ex. 1003, 7:18–22.
`Petitioner contends that “[e]ach ‘slice’ of the data stream 40
`corresponds to a ‘media element.’” Pet. 19 (citing Polish Decl. ¶ 108). In
`support, Dr. Polish testifies that
`Carmel teaches “[e]ach slice contains a segment of video and/or
`audio data, corresponding to a respective, successive time
`interval T1, T2, T3, etc.” (Carmel, 7:23–25.) The compilation of
`slices of the data stream 40 thus “represent the program” of
`audiovisual data that was provided to computer 34.
`
`Polish Decl. ¶ 108; Pet. 19.
`These segments (i.e., slices) meet the “media data elements”
`limitation of the step because, according to Petitioner, “[t]he ’636 patent
`explains media data elements are segments of the media data . . . provided to
`the server system.” Pet. 19–20 (citing Ex. 1001, 6:30–32, 7:16–35, 8:4–6,
`9:36–38, 9:45–45, 10:9–12; Polish Decl. ¶ 108).
`As for “each media data element comprising a digitally encoded
`portion of the program,” Petitioner contends that a person of ordinary skill in
`the art would understand that “audiovisual data received by the computer 34
`would be digitally encoded.” Pet. 20 (Polish Decl. ¶ 109). Dr. Polish
`
`19
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`explains that, when “the digitally encoded data stream 40 (i.e., program) is
`sliced into portions, . . . each data slice comprises a portion of the program,”
`and thus would be digitally encoded as well. Polish Decl. ¶ 109; Pet. 20.
`
`As for “each media data element . . . having a playback rate,”
`Petitioner contends that “[e]ach data slice (media data element) [of Carmel’s
`data stream 40] has a playback rate.” Pet. 20. In support, Dr. Polish testifies
`that
`
`[a] person of ordinary skill in the art would therefore understand
`that a slice of audiovisual data, such as a segment of a video or a
`segment of an audio recording, would naturally have a playback
`rate, i.e. the rate at which that segment of video or audio plays at
`normal speed from beginning to end. This is confirmed by
`Carmel, which explains each slice corresponds to “a respective,
`successive time interval labeled T1, T2, T3, etc.” (Carmel, 7:23-
`25.)
`
`Polish Decl. ¶ 111; Pet. 21.
`
`In our view, at this stage, Petitioner sufficiently shows on this record
`that Carmel teaches the “supplying” step as claimed.
`1[b(ii)] serially identifying the media data elements, said serial
`identification indicating a time sequence of the media data
`elements, and
`Petitioner contends that it would have been obvious to one of ordinary
`
`skill in the art to serially identify “media data elements” to indicate a time
`sequence. Pet. 22–24.
`Petitioner explains that Carmel teaches that each slice (i.e., “media
`data element”) of data stream 40 is identified via a “running slide index.”
`Pet. 22 (citing Ex. 1003, 2:6–7 (“[e]ach slice is preferably assigned a
`respective slice index”), 7:27–28). According to Petitioner, “the slices are
`
`20
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`identified ‘serially’ because each new slice (and corresponding slice index)
`is identified by the next available spot in the running slice index.” Id. (citing
`Polish Decl. ¶ 115).
`
`Petitioner contends that it is obvious that the serial identifications (of
`the slices of Carmel’s data stream 40) “indicat[e] a time sequence.”
`Pet. 23. This is so because, according to Dr. Polish, a person of ordinary
`skill in the art “would understand the order of slice indices in the running
`slice index indicates a ‘time sequence’ of the slices.” Polish Decl. ¶ 116
`(footnote omitted); Pet. 23.
`In our view, at this stage, Petitioner sufficiently shows on this record
`that Carmel teaches the “serially identifying” step as claimed.
`1[b(iii)] storing the media data elements in a data structure
`under the control of the server system;
`Petitioner contends that Carmel teaches storing media elements in a
`
`data structure under the control of the server system. Pet. 24–25.
`
`Petitioner explains that Carmel teaches “the memory available on
`server 36 is limited, and files 42, 44, 46, etc., will be stored on the server and
`erased therefrom in a ‘first-in-first-out’ sequence.” Pet. 25 (quoting
`Ex. 1003, 7:55–58). According to Petitioner, such a storage within a
`server/memory meets the claimed “data structure” because the ’636 patent
`similarly describes the “data structure” operating in a first in, first out,
`sequence. Id. (“The ’636 patent [also] characterizes the claimed ‘data
`structure’ as a FIFO (first in, first out) buffer.”) (citing Ex. 1001, 7:15–35
`(“FIFO Server Buffer Implementation”)).
`
`Petitioner further contends that “Carmel’s server 36 and/or the
`memory structure within that server 36 (data structure) is ‘under the control
`
`21
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`of the server system’ [as claimed]” because server 36 is part of Carmel’s
`server system. Pet. 25 (citing Polish Decl. ¶ 122).
`
`In our view, at this stage, Petitioner sufficiently shows on this record
`that Carmel teaches the “storing” step as claimed.
`1[c] 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,
`Limitation 1[c] requires the server system to receive requests via a
`
`data connection over the Internet for the stored media elements. Petitioner
`explains that Carmel teaches this. Pet. 25–26. “Carmel’s server 36 receives
`requests via Internet data connections for one or more of the data slices
`(media data elements) stored in server 36.” Pet. 26 (citing Polish Decl.
`¶ 126). Petitioner reproduces Figure 2 (see supra) which, according to
`Petitioner, “clearly teaches the client devices submit requests for multimedia
`data, and the server system receives those requests.” Id. (citing Polish Decl.
`¶¶ 126–127).
`In our view, at this stage, Petitioner sufficiently shows on this record
`that Carmel teaches the “receiving” step as claimed.
`1[c(i)] each received request specifying one or more serial
`identifiers of the requested one or more media data elements,
`Limitation 1[c(i)] further requires that each received request specify a
`
`serial identifier of the requested media data elements. Petitioner explains
`that Carmel teaches this because “Carmel discloses the client request for a
`particular data slice 42, 44, 46, etc. specifies the slice by referencing the
`corresponding slice index.” Pet. 27. As an example, Petitioner quotes
`Carmel: “When one of computers 30 connects to server 36 and begins to
`
`22
`
`
`
`IPR2022-01413
`Patent 9,762,636 B2
`
`
`download the data stream, it first reads the index file [50] in order to identify
`at what point in stream 40 to begin and to start receiving the data stream.”
`Id. (quoting Ex. 1003, 8:1–5; cit