throbber
Trials@uspto.gov Paper 7
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket