throbber
Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper 7
`Date: March 10, 2023
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`AMAZON.COM, INC., AMAZON WEB SERVICES, INC.,
`and AMAZON.COM SERVICES LLC,
`Petitioner,
`
`v.
`
`WAG ACQUISITION, L.L.C.,
`Patent Owner.
`____________
`
`IPR2022-01433
`Patent 9,762,636 B2
`____________
`
`
`
`
`Before HUBERT C. LORIN, JOHN A. HUDALLA, and
`STEVEN M. AMUNDSON, Administrative Patent Judges.
`
`AMUNDSON, Administrative Patent Judge.
`
`
`
`
`DECISION
`Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`
`I. INTRODUCTION
`Amazon.com, Inc., Amazon Web Services, Inc., and Amazon.com
`Services LLC (collectively “Petitioner”) filed a Petition requesting an inter
`partes review of claims 1–12 in U.S. Patent No. 9,762,636 B2
`(Exhibit 1001, “the ’636 patent”) under 35 U.S.C. §§ 311–319. Paper 2
`(“Pet.”). WAG Acquisition, L.L.C. (“Patent Owner”) filed a Preliminary
`Response. Paper 6 (“Prelim. Resp.”).
`Under 37 C.F.R. § 42.4(a), we have authority to determine whether
`to institute an inter partes review. We may institute an inter partes review
`only if “the information presented in the petition filed under section 311
`and any response filed under section 313 shows that there is a reasonable
`likelihood that the petitioner would prevail with respect to at least 1 of
`the claims challenged in the petition.” 35 U.S.C. § 314(a) (2018). The
`“reasonable likelihood” standard is “a higher standard than mere notice
`pleading” but “lower than the ‘preponderance’ standard to prevail in a final
`written decision.” Hulu, LLC v. Sound View Innovations, LLC, IPR2018-
`01039, Paper 29 at 13 (PTAB Dec. 20, 2019) (precedential).
`Based on the current record and for the reasons explained below,
`Petitioner has shown that there is a reasonable likelihood that it would
`prevail with respect to at least one of the challenged claims. Thus, we
`institute an inter partes review of claims 1–12 in the ’636 patent on all
`challenges included in the Petition.
`II. BACKGROUND
`A. Real Parties in Interest
`Petitioner identifies the following real parties in interest:
`Amazon.com, Inc., Amazon Web Services, Inc., and Amazon.com Services
`
`2
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`LLC. Pet. 1. Patent Owner identifies itself as the real party in interest.
`Paper 4, 2. The parties do not raise any issue about real parties in interest.
`B. Related Matters
`Petitioner and Patent Owner identify the following civil actions where
`Patent Owner has asserted the ’636 patent and related patents against
`Petitioner and other alleged infringers:
`• WAG Acquisition, L.L.C. v. Amazon.com, Inc. et al., No.
`6:21-cv-00815 (W.D. Tex. filed Aug. 6, 2021);
`• WAG Acquisition, L.L.C. v. Google LLC et al., No.
`6:21-cv-00816 (W.D. Tex. filed Aug. 6, 2021); and
`• WAG Acquisition, L.L.C. v. The Walt Disney Company et
`al., No. 2:21-cv-08230 (C.D. Cal. filed Oct. 18, 2021).
`Pet. 1–2; Paper 4, 2.
`Petitioner and Patent Owner identify the following Board proceedings
`as related matters involving the ’636 patent or a related patent asserted
`against Petitioner in a civil action:
`• The Walt Disney Company et al. v. WAG Acquisition,
`L.L.C., IPR2022-01227 (U.S. Patent No. 9,762,636 B2);
`• The Walt Disney Company et al. v. WAG Acquisition,
`L.L.C., IPR2022-01228 (U.S. Patent No. 9,742,824 B2);
`• The Walt Disney Company et al. v. WAG Acquisition,
`L.L.C., IPR2022-01346 (U.S. Patent No. 9,729,594 B2);
`• Google LLC v. WAG Acquisition, L.L.C., IPR2022-01411
`(U.S. Patent No. 9,729,594 B2);
`• Google LLC v. WAG Acquisition, L.L.C., IPR2022-01412
`(U.S. Patent No. 9,742,824 B2);
`• Google LLC v. WAG Acquisition, L.L.C., IPR2022-01413
`(U.S. Patent No. 9,762,636 B2);
`
`3
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`
`• Amazon.com, Inc. et al. v. WAG Acquisition, L.L.C.,
`IPR2022-01429 (U.S. Patent No. 9,729,594 B2); and
`• Amazon.com, Inc. et al. v. WAG Acquisition, L.L.C.,
`IPR2022-01430 (U.S. Patent No. 9,742,824 B2).
`Pet. 5; Paper 4, 4–5; Prelim. Resp. 5.
`Additionally, Petitioner and Patent Owner identify numerous civil
`actions and Office proceedings involving patents related to the ’636 patent,
`e.g., U.S. Patent No. 8,122,141 B2. Pet. 2–4; Paper 4, 2–8.
`C. The ’636 Patent (Exhibit 1001)
`The ’636 patent, titled “Streaming Media Delivery System,” issued
`on September 12, 2017, from an application filed on October 3, 2016.
`Ex. 1001, codes (22), (45), (54). The patent identifies that application as the
`latest in a series of continuation and continuation-in-part applications that
`started with an application filed on March 28, 2001. Id. at 1:6–22,
`code (63). The patent claims priority to a provisional application filed on
`September 12, 2000. Id. at 1:22–28, code (60). The patent states that the
`invention relates to “systems and methods for delivering streaming media,
`such as audio and video, on the Internet.” Id. at 1:52–55; see id. at
`code (57).
`The ’636 patent describes problems with conventional streaming
`technologies. See Ex. 1001, 2:34–3:41. As an example, “users viewing or
`listening to streaming content over Internet connections often encounter
`interruptions,” called “dropouts,” due to “unanticipated transmission delays
`and losses that are inherent in many Internet protocols.” Id. at 2:34–40; see
`id. at 5:25–32. Conventional streaming technologies employ “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
`
`4
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`dropouts.” Id. at 2:42–45. But this “process requires the user to wait until
`enough of the media file is buffered in memory before listening or viewing
`can begin,” e.g., to wait “from ten to twenty seconds or more.” Id. at
`2:45–47, 2:53–54.
`As another example, the “audio or video data is delivered from the
`source at the rate it is to be played out.” Ex. 1001, 2:63–65; see id. at
`5:60–65, 6:8–12, 8:64–67. Because “transmission of audio/video media data
`to the user takes place at the rate it is played out, the user’s buffer level can
`never be increased or replenished while it is playing” if Internet slowdowns
`or gaps cause the user’s buffer level to decrease from its initial level. Id. at
`3:5–11; see id. at 10:34–35. “In time, extended or repeated occurrences of
`these gaps empty the user’s buffer.” Id. at 3:11–13; see id. at 3:34–35.
`When that occurs, the “audio/video material stops playing, and the buffer
`must be refilled to” its initial level before playing resumes. Id. at 3:13–15;
`see id. at 3:35–40.
`The ’636 patent identifies a need for “improved systems and methods
`for delivering streaming content over the Internet” that:
`(1)
`“facilitate continuous transmission of streaming content”;
`(2)
`“respond on demand without objectionable buffering
`delay”; and
`“perform without disruption or dropouts.”
`(3)
`Ex. 1001, 3:45–50.
`
`5
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`
`Figure 1 in the ’636 patent (reproduced below) depicts a system for
`delivering streaming content over the Internet:
`
`
`Figure 1 illustrates a streaming system including server 12 with server
`buffer 14 and buffer manager 16 and at least one user computer 18 with user
`buffer 20 and buffer manager 22. Ex. 1001, 4:23–25, 6:32–37, 6:48–59,
`Fig. 1. Server 12 and user computer 18 communicate “via the Internet 10
`or other data communications medium.” Id. at 6:48–51.
`Server buffer 14 stores time-sequenced data elements. Ex. 1001,
`6:30–36. Server buffer 14 “is filled the first time the media source
`
`6
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`connection is established or a disk file is read.” Id. at 8:1–2. “Once server
`buffer 14 is full, for each new data element received into the buffer the
`oldest data element is deleted (or displaced) from the buffer.” Id. at 8:7–9.
`After user computer 18 connects to server 12, the server “sends the
`media data to the user computer” at “a rate faster than the playback rate,
`which may be the highest rate that the data connection between the server
`and the user computer will support, or any lower rate that is a higher rate
`than the playback rate.” Ex. 1001, 8:13–20; see id. at 8:59–63, 9:36–39,
`14:60–62. Server 12 provides data elements at that rate until “the
`predetermined amount of data that had been stored in the server buffer has
`been transferred to” the user computer buffer. Id. at 8:20–22. After
`transferring the contents of the server buffer to the user computer buffer and
`reaching a steady-state condition, each data element “is immediately sent out
`to the user computer” when it arrives at the server. Id. at 8:23–26.
`If, however, the user computer buffer “begins to deplete or becomes
`depleted due to networking interruptions, the server will attempt to send as
`much data as is necessary to rebuild” the user computer buffer “to the proper
`level, again at higher than a playback rate.” Ex. 1001, 10:22–27. This
`permits rebuilding the user computer buffer “under circumstances wherein
`Internet interruptions have blocked the normal flow of data.” Id. at
`10:27–29.
`A “data communications transport mechanism, such as the
`[Transmission Control Protocol] TCP protocol, may be used for the reliable
`delivery of data in an ordered sequence from the source of the media data to
`the server, or from the server to the media player software of the user
`computer.” Ex. 1001, 8:36–40. “Resending missing data is the
`
`7
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`responsibility of the reliable transport mechanism.” Id. at 8:40–41. “The
`server buffer 14 ‘sends’ data by delivering it to the transport mechanism.”
`Id. at 8:41–43. “The transport mechanism actually manages transmission of
`the data across the communications medium, and has processes to determine
`if all the data that has been sent has been received by the destination.” Id. at
`8:43–46.
`“All media data to be delivered to a user computer may be sent at a
`higher than playback rate, either by the server buffer 14 passing media data
`to the transport mechanism, or by the transport mechanism delivering or
`redelivering the media data to the user computer.” Ex. 1001, 8:59–63.
`The ’636 patent describes an embodiment where the “server buffer
`manager, or the media source, provides for sequentially numbering the
`media data elements.” Ex. 1001, 14:42–45. The “user computer transmits a
`request to the server to send one or more data elements, specifying the serial
`numbers of the data elements.” Id. at 14:51–53. The “server responds by
`sending the requested data elements, and depends upon the reliable
`transmission protocol to assure delivery.” Id. at 14:53–56. The “user
`computer then continues with additional data requests for the duration of
`playing the audio/video material.” Id. at 14:56–58. “In this manner, the user
`computer, not the server, maintains the record of the highest data element
`number stored in the user computer buffer.” Id. at 14:58–60.
`
`8
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`
`Figure 3 in the ’636 patent (reproduced below) depicts steps in a
`method for delivering streaming content over the Internet:
`
`
`Figure 3 illustrates a flowchart with steps 32 to 42 for “distributing from a
`server via the Internet streaming media composed of a plurality of time-
`sequenced data elements.” Ex. 1001, 4:28–29, 13:27–30, Fig. 3.
`
`9
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`
`At step 32, time-sequenced data elements are generated or received.
`Ex. 1001, 13:31–32, Fig. 3. At step 34, “a predetermined number of the data
`elements is sequentially loaded” into a server buffer. Id. at 13:32–33, Fig. 3.
`Steps 32 and 34 repeat “indefinitely as long as there is media data
`available.” Id. at 13:33–35.
`At step 36, “a group of the data elements is sequentially sent” via the
`Internet “from the server buffer to a user computer connected to the Internet,
`more rapidly than they are played out by the user system.” Ex. 1001,
`13:35–38, Fig. 3. At step 38, “the sent group of data elements is loaded”
`into “a user buffer associated with the user computer.” Id. at 13:38–40,
`Fig. 3. And at step 40, the “user computer immediately plays” the “received
`portion of the media on the user computer.” Id. at 13:40–42, Fig. 3.
`At step 42, the user buffer is checked to determine if it is full.
`Ex. 1001, Fig. 3. If “the user buffer is not full” at step 42, then “additional
`data elements are sent to the user computer,” again “more rapidly” than the
`data elements are “played out by the user system.” Id. at 13:42–45. But if
`“the user buffer is full” at step 42, then “the system waits until new media
`data is delivered to the server buffer.” Id. at 13:45–47.
`This process repeats “until the entire media file is played at the user
`computer.” Ex. 1001, 13:47–48.
`D. The Challenged Claims
`Petitioner challenges independent method claim 1, claims 2–4 that
`depend directly or indirectly from claim 1, independent system claim 5,
`claims 6–8 that depend directly or indirectly from claim 5, independent
`computer-program-product claim 9, and claims 10–12 that depend directly
`or indirectly from claim 9. Pet. 6, 8, 12–63. Claims 1 and 9 exemplify the
`
`10
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`challenged claims and read as follows (with formatting added for clarity and
`with numbers and letters added for reference purposes):1
`1. [1.a] 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:
`[1.b] 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.c] upon receipt of the stream by the server system,
`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.d] serially identifying the media data elements,
`said serial identification indicating a time sequence of the
`media data elements, and
`[1.e] storing the media data elements in a data
`structure under the control of the server system;
`[1.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 a plurality
`of user systems; and
`[1.g] 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 We use the same numbers and letters that Petitioner uses to identify the
`claim language. See Pet. 18–58.
`
`11
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`
`[1.h] 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.i] each sending is at a transmission rate as fast as the
`data connection between the server system and each requesting
`user system allows;
`[1.j] 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.k] 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.l] 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.
`9. [9.a] A computer program product for distributing a live
`audio or video program over the Internet from a server system
`comprising at least one computer to a plurality of user systems,
`the computer program product comprising a non-transitory
`computer readable storage medium having program instructions
`embodied therewith, the program instructions comprising:
`[9.b] instructions executable to cause one of the at least
`one computers to receive a continuous digitally encoded stream
`for the audio or video program, via a data connection from a
`live source, in real time;
`[9.c] instructions executable to cause one of the at least
`one computers, upon receipt of the stream by the server system,
`to supply, 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,
`
`12
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`
`[9.d] to serially identify the media data elements,
`said serial identification indicating a time sequence of the
`media data elements, and
`[9.e] to store the media data elements in a data
`structure under the control of the server system;
`[9.f] instructions executable to cause one of the at least
`one computers to receive 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 in [sic] 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 a plurality of user systems; and
`[9.g] instructions executable to cause one of the at least
`one computers to send, responsive to the requests, 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,
`[9.h] 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;
`[9.i] each sending is at a transmission rate as fast as the
`data connection between the server system and each requesting
`user system allows;
`[9.j] 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;
`[9.k] 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
`[9.l] all of the media data elements that are sent by the
`server system to the requesting user systems are sent from the
`
`13
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`
`Carmel
`
`1005
`
`1006
`
`data structure under the control of the server system as the
`media data elements were first stored therein.
`Ex. 1001, 16:28–17:8, 18:10–65.
`E. The Asserted References
`For its challenges, Petitioner relies on the following references:
`Name
`Reference
`Exhibit
`US 6,389,473 B1, issued May 14, 2002
`(based on an application filed March 24, 1999)
`M.H. Willebeek-LeMair et al., Bamba–Audio and
`Video Streaming over the Internet, IBM Journal
`of Research and Development, Vol. 42, No. 2,
`269–80 (March 1998)
`US 6,175,862 B1, issued January 16, 2001
`(based on an application filed June 17, 1998)
`Pet. 7–8. Petitioner asserts that Carmel and Feig qualify as prior art “under
`at least 35 U.S.C. § 102(e)” and that Willebeek qualifies as prior art “under
`at least 35 U.S.C. § 102(b).” Id. at 7; see 35 U.S.C. § 102(b), (e) (2006). 3
`At this stage of the proceeding, Patent Owner does not dispute that
`each reference qualifies as prior art. See, e.g., Prelim. Resp. 18–39.
`
`Willebeek
`
`Feig2
`
`1031
`
`
`2 Petitioner refers to this patent by the name of the inventor listed second.
`For consistency, we follow the same convention.
`3 The Leahy-Smith America Invents Act (“AIA”), Pub. L. No. 112-29,
`125 Stat. 284 (2011), amended 35 U.S.C. § 102 and § 103 effective
`March 16, 2013. Because the effective filing date of the challenged claims
`predates the AIA’s amendments to § 102 and § 103, this decision refers to
`the pre-AIA versions of § 102 and § 103.
`14
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`
`F. The Asserted Challenge to Patentability
`Petitioner asserts the following challenge to patentability:
`Claim(s) Challenged
`35 U.S.C. §
`Reference(s)/Basis
`1–12
`103(a)
`Carmel, Feig, Willebeek
`Pet. 8, 18–63.
`
`G. Testimonial Evidence
`To support its challenges, Petitioner relies on the declaration of Kevin
`Jeffay, Ph.D. (Exhibit 1002, “Jeffay Decl.”). Dr. Jeffay states, “I received a
`Ph.D. in computer science from the University of Washington in 1989” and
`before that “received a M.Sc. degree in computer science from the
`University of Toronto in 1984, and a B.S. degree with Highest Distinction in
`mathematics from the University of Illinois at Urbana-Champaign in 1982.”
`Ex. 1002 ¶ 4. Dr. Jeffay also states, “I have been asked by the parties
`requesting this review, Amazon.com, Inc., Amazon Web Services, Inc., and
`Amazon.com Services LLC (collectively ‘Petitioner’) to analyze U.S. Patent
`No. 9,762,636” and “to provide my opinions regarding the patentability of
`claims 1–12 of the ’636 patent.” Id. ¶ 1.
`Petitioner also relies on the declaration of Rachel J. Watters
`(Exhibit 1007, “Watters Decl.”). Ms. Watters states, “I have a master’s
`degree in Library and Information Studies from the University of
`Wisconsin-Madison.” Ex. 1007, 1. Ms. Watters also states, “I have worked
`as a librarian at the University of Wisconsin library system since 1998,
`starting as a graduate student employee in the Kurt F. Wendt Engineering
`Library and WTS, then as a librarian in Interlibrary Loan at Memorial
`Library.” Id.
`
`15
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`
`III. PATENTABILITY ANALYSIS
`A. Legal Principles: Obviousness
`A patent may not be obtained “if the differences between the subject
`matter sought to be patented 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.”
`35 U.S.C. § 103(a) (2006). An obviousness analysis involves underlying
`factual inquiries including (1) the scope and content of the prior art;
`(2) differences between the claimed invention and the prior art; (3) the level
`of ordinary skill in the art; and (4) where in evidence, objective indicia of
`nonobviousness, such as commercial success, long-felt but unsolved needs,
`and failure of others. 4 Graham v. John Deere Co., 383 U.S. 1, 17−18, 35–36
`(1966); Apple Inc. v. Samsung Elecs. Co., 839 F.3d 1034, 1047–48
`(Fed. Cir. 2016) (en banc). When evaluating a combination of references,
`an obviousness analysis should address “whether there was an apparent
`reason to combine the known elements in the fashion claimed by the patent
`at issue.” KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007).
`We analyze the obviousness issues according to these principles.
`B. Level of Ordinary Skill in the Art
`Factors pertinent to determining the level of ordinary skill in the art
`include (1) the educational level of the inventor; (2) the type of problems
`encountered in the art; (3) prior-art solutions to those problems; (4) the
`rapidity with which innovations are made; (5) the sophistication of the
`technology; and (6) the educational level of workers active in the field.
`
`4 The record does not include evidence or argument regarding objective
`indicia of nonobviousness.
`
`16
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`Envtl. Designs, Ltd. v. Union Oil Co., 713 F.2d 693, 696–97 (Fed. Cir.
`1983). Not all factors may exist in every case, and one or more of these or
`other factors may predominate in a particular case. Id. These factors are not
`exhaustive, but merely a guide to determining the level of ordinary skill in
`the art. Daiichi Sankyo Co. v. Apotex, Inc., 501 F.3d 1254, 1256 (Fed. Cir.
`2007). Moreover, the prior art itself may reflect an appropriate skill level.
`Okajima v. Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001).
`Petitioner asserts that a person of ordinary skill in the art “would have
`had a bachelor’s degree in computer science, computer engineering, or
`electrical engineering, or the equivalent, and at least two years of work
`experience in streaming media systems for delivering audio and video.”
`Pet. 9. Petitioner also asserts that “[a]dditional education could have
`substituted for professional experience, and significant work experience
`could have substituted for formal education.” Id. Dr. Jeffay’s testimony
`supports Petitioner’s assertions. See Ex. 1002 ¶ 51.
`For purposes of the Preliminary Response, Patent Owner “does not
`dispute” Petitioner’s description of an ordinarily skilled artisan. Prelim.
`Resp. 13.
`Based on the current record and for purposes of institution, we accept
`Petitioner’s description of an ordinarily skilled artisan as consistent with the
`’636 patent and the asserted prior art.
`C. Claim Construction
`We construe claim terms “using the same claim construction
`standard” that district courts use to construe claim terms in civil actions
`under 35 U.S.C. § 282(b). See 37 C.F.R. § 42.100(b) (2022). Under that
`standard, claim terms “are given their ordinary and customary meaning,
`
`17
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`which is the meaning the term would have to a person of ordinary skill in the
`art at the time of the invention.” Power Integrations, Inc. v. Fairchild
`Semiconductor Int’l, Inc., 904 F.3d 965, 971 (Fed. Cir. 2018) (citing Phillips
`v. AWH Corp., 415 F.3d 1303, 1312–13 (Fed. Cir. 2005) (en banc)). The
`meaning of claim terms may be determined by “look[ing] principally to the
`intrinsic evidence of record, examining the claim language itself, the written
`description, and the prosecution history, if in evidence.” DePuy Spine, Inc.
`v. Medtronic Sofamor Danek, Inc., 469 F.3d 1005, 1014 (Fed. Cir. 2006)
`(citing Phillips, 415 F.3d at 1312–17).
`Petitioner asserts that the challenged claims “should be interpreted
`according to their plain and ordinary meaning” and does not propose a
`construction for any claim language. Pet. 11–12.
`Patent Owner does not propose a construction for any claim language.
`See Prelim. Resp. 13–18.
`Based on the current record, we determine that no claim term requires
`an explicit construction to decide whether Petitioner satisfies the “reasonable
`likelihood” standard for instituting trial. “[O]nly those terms need be
`construed that are in controversy, and only to the extent necessary to resolve
`the controversy.” Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795,
`803 (Fed. Cir. 1999); see Nidec Motor Corp. v. Zhongshan Broad Ocean
`Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017).
`D. Alleged Obviousness over Carmel, Feig, and Willebeek: Claims 1–12
`Petitioner contends that claims 1–12 are unpatentable under § 103(a)
`as obvious over the combination of Carmel, Feig, and Willebeek. See Pet.
`18–63. Patent Owner disputes Petitioner’s contentions. See Prelim. Resp.
`18–39. Below, we provide overviews of Carmel, Feig, and Willebeek.
`
`18
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`Then, we consider the obviousness issues. As explained below, Petitioner
`establishes sufficiently for purposes of institution that the combined
`disclosures in Carmel, Feig, and Willebeek teach the subject matter of
`claims 1–12.
`
`1. OVERVIEW OF CARMEL (EXHIBIT 1005)
`Carmel is a U.S. patent titled “Network Media Streaming,” filed on
`March 24, 1999, and issued on May 14, 2002. Ex. 1005, codes (12), (22),
`(45), (54). Carmel states that the invention “relates generally to network
`data communications, and specifically to real-time multimedia broadcasting
`over a network.” Id. at 1:10–12; see id. at code (57).
`As background, Carmel explains that “[i]n network broadcasting, data
`are transmitted over a network in real time from a single transmitting
`computer to a plurality of clients simultaneously.” Ex. 1005, 1:16–18. The
`network may include “a LAN, a WAN, an intranet or a public network such
`as the Internet.” Id. at 1:18–20. The data may include “multimedia data,
`typically comprising images and sound,” such as “still images, video,
`graphics, animation or any combination thereof.” Id. at 1:20–22, 2:35–36.
`Carmel explains that the objects of the invention include the
`following:
`(1)
`
`“provid[ing] substantially continuous, high-bandwidth
`data streaming over a network using common, existing
`server and network infrastructure”;
`“provid[ing] data broadcasting capability, particularly
`for multimedia data, without the need for a dedicated
`broadcast computer system”; and
`“enabl[ing] a personal computer to remotely broadcast a
`multimedia program through an Internet service provider
`
`(2)
`
`(3)
`
`19
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`
`(ISP) using common, universally-supported Internet
`communication protocols.”
`Ex. 1005, 1:51–58, 1:63–67.
`Carmel attempts to achieve those objects with a system and method
`for “real-time broadcasting from a transmitting computer to one or more
`client computers over a network.” Ex. 1005, 3:25–39, 14:19–32,
`15:63–16:8, code (57). The transmitting computer “generates a data stream
`. . . divided into a sequence of segments or slices of the data, preferably time
`slices, wherein the data are preferably compressed.” Id. at 2:1–6.
`Preferably, “each segment or slice is contained in a separate, respective file,”
`and each file “includes one or more time stamps, indicating a real time at
`which the data in the file were recorded or an elapsed time relative to the
`beginning of stream.” Id. at 2:22–23, 7:27–31. “Each slice is preferably
`assigned a respective slice index.” Id. at 2:6–7; see id. at 7:27–28.
`The transmitting computer “uploads the sequence of slices to” the
`network server “substantially in real time” and “preferably using an Internet
`protocol, most preferably the File Transfer Protocol (FTP).” Ex. 1005,
`2:7–10; see id. at 3:60–62, 5:19–21, 6:50–54. The client computers
`“download the data stream from” the network server “preferably using an
`Internet protocol, as well, most preferably the Hypertext Transfer Protocol
`(HTTP)” or another protocol “similarly known in the art.” Id. at 2:11–15;
`see id. at 3:63–66, 5:25–28, 7:5–9, 10:37–39, 11:1–2, 15:18–21.
`The transmitting computer and the client computers may “monitor the
`uploading and downloading of data to and from the server, respectively, in
`order to determine the amount of time required to convey each slice and to
`verify that the slices are conveyed at a sufficient rate.” Ex. 1005, 2:51–56;
`
`20
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`see id. at 3:8–11, 7:35–40, 10:55–56, 11:9–11. “When the data stream
`comprises multimedia data, the data rate should be generally equal to or
`faster than the rate at which the data are generated at the transmitting
`computer.” Id. at 2:56–59.
`The network server provides the data slices “at multiple resolution
`or quality levels.” Ex. 1005, 3:5–6. Each level “has a different degree of
`data compression, and thus corresponds to a different data bandwidth
`requirement.” Id. at 3:6–8. The “compression level of the data is varied” to
`“adjust the data streaming rate to the available bandwidth” of the data link
`between the network server and a client computer. Id. at 7:45–49; see id.
`at 3:6–11, 4:43–47, 9:6–8. For example, “the compression ratio may be
`adjusted” to “match the data stream bandwidth to the available link
`bandwidth.” Id. at 11:45–48; see id. at 3:18–21. Hence, “steps are taken to
`increase the data transmission or reception rate” if “a lag is detected.” Id. at
`7:40–42.
`
`21
`
`

`

`IPR2022-01433
`Patent 9,762,636 B2
`
`
`Carmel’s Figure 2 (reproduced below) depicts a system for real-time
`broadcasting from a transmitting computer to one or more client computers
`over a network:
`
`
`
`Figure 2 illustrates computer system 32 including a plurality of client
`computers 30, transmitting computer 34, and network server 36 that
`“communicate over network 28, preferably using the well-known Internet
`Protocol (IP).” Ex. 1005, 6:24–31, Fig. 2; see id. at 5:43–45.
`Transm

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