`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