`571-272-7822
`
`
`
`
`
`
`Paper 7
`Entered: January 4, 2017
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`
`WEBPOWER, INC.,
`Petitioner,
`
`v.
`
`WAG ACQUISITION, LLC,
`Patent Owner.
`____________
`
`Case IPR2016-01238
`Patent 8,122,141 B2
`
`____________
`
`
`
`
`
`Before TREVOR M. JEFFERSON, BRIAN J. McNAMARA, and
`PATRICK M. BOUCHER, Administrative Patent Judges.
`
`BOUCHER, Administrative Patent Judge.
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`On June 21, 2016, WebPower, Inc. (“Petitioner”) filed a Petition
`
`(Paper 1, “Pet.”) pursuant to 35 U.S.C. §§ 311–319 to institute an inter
`
`partes review of claims 1–28 of U.S. Patent No. 8,122,141 B2 (“the ’141
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`patent”). WAG Acquisition, LLC (“Patent Owner) filed a Preliminary
`
`Response (Paper 6, “Prelim. Resp.”) on October 7, 2016. Applying the
`
`standard set forth in 35 U.S.C. § 314(a), which requires demonstration of a
`
`reasonable likelihood that Petitioner would prevail with respect to at least
`
`one challenged claim, we institute an inter partes review of claims 10–23 of
`
`the ’141 patent. The Board has not made a final determination on the
`
`patentability of any claim.
`
`
`
`I. BACKGROUND
`
`A. The ’141 Patent
`
`The ’141 patent discloses a system for streaming media, such as audio
`
`or video, via the Internet with reduced playback interruptions. Ex. 1001,
`
`col. 4, ll. 39–44. Data interruptions can be recovered while a media player
`
`continues to play the audio or video material. Id. at col. 4, ll. 48–50.
`
`Figure 1 of the ’141 patent is reproduced below.
`
`2
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`
`
`
`Figure 1 is a schematic diagram that illustrates elements of a streaming
`
`media buffering system. Id. at col. 10, ll. 7–9. Server 12 is connected to the
`
`Internet for transmitting sequenced streaming-media data elements. Id. at
`
`col. 10, ll. 22–25. Associated with server 12 are buffer manager 16 and
`
`first-in–first-out (“FIFO”) buffer 14, which stores at least one of the data
`
`elements for transmission. Id. at col. 10, ll. 25–27. Buffer manager 16
`
`receives the media data, supplies the media data in order to FIFO buffer 14,
`
`and maintains pointers 24a–24n into the buffer for user computers,
`
`indicating the last media data element that has been sent to respective users
`
`and thus indicating the next element or elements to be sent. Id. at col. 10, ll.
`
`30–38. Once FIFO buffer 14 is full, the oldest data elements in the buffer
`
`are deleted as new elements are received. Id. at col. 10, ll. 38–40. A
`
`predetermined number of data elements are kept in FIFO buffer 14. Id. at
`
`col. 10, ll. 40–41.
`
`3
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`
`At least one user computer 18 is connected to server 12 via the
`
`Internet. Id. at col. 10, ll. 45–46. User buffer 20 is associated with user
`
`computer 18 and stores a predetermined number of the media data elements.
`
`Id. at col. 10, ll. 47–49. Buffer manager 22, associated with user computer
`
`18, receives and stores a predetermined number of media data elements
`
`received by the media player, plays the data out sequentially as audio and/or
`
`video, and deletes media data elements from buffer 20 as they are played out
`
`to maintain approximately the predetermined number of data elements in the
`
`user’s buffer. Id. at col. 10, ll. 53–59, col. 8, ll. 31–34.
`
`
`
`B. Illustrative Claim
`
`Independent claims 1, 10, and 19 are illustrative of the claims at issue:
`
`1. A method for distributing streaming media via a data
`communications medium such as the Internet to at least one user
`system of at least one user, the streaming media comprising a
`plurality of sequential media data elements for a digitally
`encoded audio or video program, comprising
`providing a server programmed to receive requests from
`the user system for media data elements corresponding to
`specified serial identifiers and to send media data elements to the
`user system responsive to said requests, at a rate more rapid than
`the rate at which said streaming media is played back by a user;
`and
`
`providing a machine-readable medium accessible to said
`user, on which
`there has been recorded software for
`implementing a media player for receiving and playing the
`streaming media on said user system, said software being
`programmed to cause the media player to maintain a record of
`the identifier of the last data element that has been received; and
`to transmit requests to the server to send one or more data
`elements, specifying the identifiers of the data elements, as said
`media player requires in order to maintain a sufficient number of
`
`4
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`
`media data elements in the media player for uninterrupted
`playback.
`
`
`Ex. 1001, col. 13, ll. 23–44.
`
`
`10. A server for distributing streaming media via a data
`communications medium such as the Internet to at least one user
`system of at least one user, the streaming media comprising a
`plurality of sequential media data elements for a digitally
`encoded audio or video program, said user system being assumed
`to have a media player for receiving and playing the streaming
`media on said user system, which is operable to obtain media
`data elements from said server by transmitting requests to said
`server to send one or more specified media data elements, said
`server comprising
`
`at least one data storage device, memory for storing
`machine-readable executable routines and for providing a
`working memory area for routines executing on the server, a
`central processing unit for executing the machine-readable
`executable routines, an operating system, at least one connection
`to the communications medium, and a communications system
`providing a set of communications protocols for communicating
`through said at least one connection;
`routine containing
`
`a machine-readable, executable
`instructions to cause the server to assign serial identifiers to the
`sequential media data elements comprising the program;
`
`a machine-readable, executable
`routine containing
`instructions to cause the server to receive requests from the user
`system for one or more media data elements specifying the
`identifiers of the requested data elements; and
`
`a machine-readable, executable
`routine containing
`instructions to cause the server to send media data elements to
`the user system responsive to said requests, at a rate more rapid
`than the rate at which said streaming media is played back by a
`user.
`
`
`Id. at col. 13, l. 63–col. 14, l. 28.
`
`
`5
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`
`19. A non-transitory machine-readable medium on which there
`has been recorded a computer program for use in operating a
`computer to prepare streaming media content for transmission by
`a server wherein said server responds to user requests for media
`data elements identified by a serial identifier, said program
`recorded on said non-transitory machine readable medium
`comprising a routine to store and serially identify sequential data
`elements comprising said streaming media content, in a format
`capable of being served to users by said server.
`
`
`Id. at col. 14, ll. 49–58.
`
`
`C. References
`
`Petitioner relies on the following references. Pet. 7–10.
`
`Oct. 13, 1998
`US 5,822,524
`Chen
`Carmel US 6,389,473 B1 May 14, 2002
`
`
`Ex. 1002
`Ex. 1003
`
`M. H. Willebeek-LeMair, K. G. Kumar, and E. C. Snible,
`Bamba—Audio and video streaming over the Internet, 42 IBM
`J. RES. DEVELOP. 269 (March, 1998) (Ex. 1004) (“Willebeek”)
`
`International Standard ISO/IEC 11172-1, Information
`Technology—Coding of moving pictures and associated audio
`for digital storage media at up to about 1,5 Mbit/s—Part 1:
`Systems (ISO/IEC, August 1993) (Ex. 1018) (“ISO-11172-1”)
`
`International Standard ISO/IEC 11172-2, Information
`Technology—Coding of moving pictures and associated audio
`for digital storage media at up to about 1,5 Mbit/s—Part 2:
`Video (ISO/IEC, August 1993) (Ex. 1019) (“ISO-11172-2”)
`
`International Standard ISO/IEC 11172-3, Information
`Technology—Coding of moving pictures and associated audio
`
`6
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`
`for digital storage media at up to about 1,5 Mbit/s—Part 3:
`Audio (ISO/IEC, August 1993) (Ex. 1020) (“ISO-11172-3”)1
`
`
`D. Asserted Grounds of Unpatentability
`
`Petitioner challenges claims 1–28 of the ’141 patent on the following
`
`grounds. Pet. 4–5.
`
`Reference(s)
`
`Chen
`
`Chen and Willebeek
`Chen and ISO-11172
`Carmel
`
`Carmel and Willebeek
`Carmel, Willebeek, and ISO-
`11172
`Carmel and ISO-11172
`
`
`Basis(es)
`§ 102(b)
`
`§ 103(a)
`§ 103(a)
`§ 102(a)
`§ 102(e)
`§ 103(a)
`§ 103(a)
`
`Claims Challenged
`1, 2, 4–7, 9–11, 13–16, 18–20,
`23, 24, and 26–28
`8, 17, and 21
`3, 12, 22, and 25
`10, 11, 13–21, and 23
`
`1, 2, 4–9, 24, and 26–28
`3 and 25
`
`§ 103(a)
`
`12 and 22
`
`E. Related Proceedings
`
`The parties identify the following matters as involving the ’141
`
`patent: (1) WAG Acquisition, LLC v. Sobonito Investments, Ltd., No. 2A14-
`
`cv-1661-ES-MAH (D.N.J.); (2) WAG Acquisition, LLC v. Multi Media, LLC,
`
`No. 2:14-cv-2340-ES-MAH (D.N.J.); (3) WAG Acquisition, LLC v. Data
`
`Conversions, Inc., No. 2:14-cv-2345-ES-MAH (D.N.J.); (4) WAG
`
`Acquisition, LLC v. Flying Crocodile, Inc., No. 2:14-cv-2674-ES-MAH
`
`
`1 In its challenges, Petitioner refers collectively to ISO-11172-1,
`ISO-11172-2, and ISO-11172-3 as “ISO-11172.” Because the challenges
`involving these references are all under 35 U.S.C. § 103(a), and because
`there is a self-evident reason to combine their teachings, we do not address
`whether they are properly considered as a single reference or as three
`separate references.
`
`7
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`(D.N.J.); (5) WAG Acquisition, LLC v. Gattyàn Group S.à r.l., No. 2:14-cv-
`
`2832-ES-MAH (D.N.J.); (6) WAG Acquisition, LLC v. FriendFinder
`
`Networks Inc., No. 2:14-cv-3456-ES-MAH (D.N.J); (7) WAG Acquisition,
`
`LLC v. Vubeology, Inc., No. 2:14-cv-4531-ES-MAH (D.N.J.); (8) WAG
`
`Acquisition, LLC v. Gamelink Int’l Ltd. No. 2:15-cv-3416-ES-MAH
`
`(D.N.J.); (9) WAG Acquisition LLC v. WebPower, Inc., No. 2:15-cv-3581-
`
`ES-MAH (D.N.J.); and (10) WAG Acquisition, LLC v. MFCXY, Inc., No.
`
`2:14-cv-3196-ES-MAH (D.N.J.). Pet. 2, Paper 4, 2–3.
`
`The ’141 patent is also the subject of IPR2015-01037. A continuation
`
`of the ’141 patent, U.S. Patent No. 8,327,011 B2, is the subject of IPR2015-
`
`01033 and IPR2016-01161. Two other related patents are the subject of
`
`further inter partes review proceedings: U.S. Patent No. 8,185,611 is the
`
`subject of IPR2015-01035 and IPR2016-01162, and U.S. Patent No.
`
`8,364,839 is the subject of IPR2015-01036.
`
`
`
`II. ANALYSIS
`
`A. Claim Construction
`
`The Board interprets claims of an unexpired patent using the broadest
`
`reasonable construction in light of the specification of the patent in which
`
`they appear. See 37 C.F.R. § 42.100(b); Cuozzo Speed Techs., LLC v. Lee,
`
`136 S. Ct. 2131, 2144–46 (2016) (upholding the use of the broadest
`
`reasonable interpretation standard); Office Patent Trial Practice Guide, 77
`
`Fed. Reg. 48,756, 48,766 (Aug. 14, 2012).
`
`Petitioner contends that no express constructions are necessary for this
`
`proceeding, and notes that in another inter partes review proceeding
`
`involving the ’141 patent, the Board explicitly determined that neither “said
`
`8
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`server responds to user requests for media data elements” nor “a routine to
`
`store and serially identify sequential data elements comprising said media
`
`contend” requires express construction. Pet. 10–11; FriendFinder Networks
`
`Inc. v. WAG Acquisition, LLC, Case IPR2015-01037, slip op. at 7–8 (PTAB
`
`Oct. 19, 2015) (Paper 8). Patent Owner does not directly address claim
`
`construction in its Preliminary Response.
`
`For purposes of this Decision, we do not construe any claim term
`
`expressly, and accord claim terms their ordinary and customary meaning.
`
`
`
`B. Grounds Based on Chen
`
`Petitioner challenges claims 1, 2, 4–7, 9–11, 13–16, 18–20, 23, 24,
`
`and 26–28 under 35 U.S.C. § 102(b) as anticipated by Chen; challenges
`
`claims 8, 17, and 21 under 35 U.S.C. § 103(a) as unpatentable over Chen
`
`and Willebeek; and challenges claims 3 and 25 under 35 U.S.C. § 103(a) as
`
`unpatentable over Chen and ISO-11172. Pet. 11–49, 67.
`
`
`
`1. Overview of Chen
`
`Chen discloses the transmission of digital data packets from a storage
`
`server computer to a playback client computer having a packet buffer that
`
`stores data packets, each data packet having a unique packet sequence
`
`number, until a multimedia application requests them. Ex. 1002, col. 5,
`
`ll. 49–59. According to Chen, the packet buffer should have enough data to
`
`minimize the possibility of not having the requested data, and enough
`
`available memory space to receive new packets. Id. at col. 6, ll. 3–7. Using
`
`a just-in-time retrieval method, Chen uses the equivalent of “Water Marks”
`
`to inform the server control and regulate the server’s transmission rate based
`
`9
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`on the amount of data in the client packet buffer as follows: (1) when the
`
`amount of data falls between high and low Water Marks, transmission takes
`
`place in a NORMAL mode, such as based on the number of frames the
`
`buffer stores; (2) when the amount of data in the packet buffer exceeds a
`
`high Water Mark, transmission enters a PAUSE mode; and (3) when the
`
`amount of data in the packet buffer falls below a low Water Mark, the
`
`delivery of packets is expedited in a RUSH mode. Id. at col. 6, l. 7–col. 7,
`
`l. 2.
`
`Chen notes that in a non-error-free embodiment, no attempt is made to
`
`recover lost packets, while in an error-free embodiment, lost packets are
`
`traced and replaced. Id. at col. 7, ll. 20–24. In the error-free embodiment,
`
`the client detects lost packets using a register that maintains the packet
`
`sequence number of the last received packet, so that if the next arriving
`
`packet differs from the last received packet number by more than +1, then a
`
`packet loss has occurred. Id. at col. 7, ll. 24–32. To deal with packet loss,
`
`the client maintains a list of lost packets that includes the packet sequence
`
`number and time-out value. Id. at col. 7, ll. 33–37. The client sends a
`
`retransmission request for the lost packet and removes that packet from the
`
`missing-packet list if the packet arrives correctly before the expiration of the
`
`time-out value; if not, the client sends another retransmission request or
`
`gives up obtaining the missing packet. Id. at col. 7, ll. 37–44.
`
`
`
`2. Claims 1–9 and 24–28
`
`Independent claim 1 recites software programmed “to transmit
`
`requests to the server to send one or more data elements, specifying the
`
`identifiers of the data elements, as said media player requires in order to
`
`10
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`maintain a sufficient number of media data elements in the media player for
`
`uninterrupted playback.” Ex. 1001, col. 13, ll. 37–44. Independent claim 24
`
`similarly recites “a routine that requests transmission of the next sequential
`
`media data elements following said last sequential media data element, as
`
`said media player requires in order to maintain a sufficient number of media
`
`data elements in the media player for uninterrupted playback.” Id. at col. 15,
`
`l. 18–col. 16, l. 3.
`
`In addressing these limitations, Petitioner asserts that Chen “discloses
`
`sending specific requests for data using command packets (Ex. 1002 at 5:59-
`
`67), and three transmission modes for sending multimedia data to the client:
`
`Normal, Rush, and Pause. Id. at 6:9-15.” Pet. 15, 40–41. We agree with
`
`Patent Owner that Petitioner’s assertion improperly conflates disparate
`
`mechanisms disclosed by Chen. Prelim. Resp. 5–6. Specifically, Chen’s
`
`disclosure of sending specific requests for data using command packets
`
`relates to circumstances in which the “packet buffer does not have the
`
`requested data available,” while the three transmission modes relate to how
`
`the amount of data available in the buffer conforms to the high and low
`
`Water Marks. See Ex. 1002, col. 5, ll. 59–61. In addressing these
`
`limitations, the Petition fails to identify disclosure that serves data with
`
`specified identifiers “to maintain a sufficient number of media data elements
`
`in the media player for uninterrupted playback,” as independent claims 1 and
`
`24 require. We agree with Patent Owner’s characterization that “[t]here is
`
`no teaching in Chen that its missing and lost packet mechanisms are
`
`triggered in any way with reference to the client buffer level.” Prelim.
`
`Resp. 6.
`
`11
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`
`Because of this deficiency, we conclude that Petitioner has not
`
`established a reasonable likelihood of prevailing on its challenge of
`
`independent claims 1 and 24 as anticipated by Chen, nor has it established a
`
`reasonable likelihood of prevailing on its challenges of claims that depend
`
`from claim 1 or claim 24, i.e., its challenges of claims 2, 4–7, 9, and 26–28
`
`as anticipated by Chen, of claim 8 as unpatentable under 35 U.S.C. § 103(a)
`
`over Chen and Willebeek, or of claims 3 and 25 as unpatentable under 35
`
`U.S.C. § 103(a) over Chen and ISO-11172.
`
`
`
`3. Claims 10–18
`
`Independent claim 10 recites “a machine-readable, executable routine
`
`containing instructions to cause the server to send media data elements to the
`
`user system responsive to said requests, at a rate more rapid than the rate at
`
`which said streaming media is played back by a user.” Ex. 1001, col. 14, ll.
`
`24–28. In addressing a similar limitation recited in independent claim 1,
`
`Petitioner contends that when in the RUSH mode, Chen discloses
`
`transmitting packets “as fast as possible.” Pet. 13 (citing Ex. 1002, claim
`
`18). Patent Owner responds that Petitioner again conflates disparate
`
`disclosures of Chen because “[t]he words ‘said requests’ [in the claim
`
`language] refer back to the elements specified by serial identifier,” while the
`
`RUSH mode “has nothing to do with any data elements specifically
`
`requested.” Prelim. Resp. 6, 8. For reasons similar to those expressed above
`
`in discussing claims 1–9 and 24–28, we agree with Patent Owner.
`
`In addition, we are not persuaded that Chen discloses anything about
`
`the speed at which packets are sent in the RUSH mode. “All the disclosures
`
`in a reference must be evaluated for what they fairly teach one of ordinary
`
`12
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`skill in the art.” In re Boe, 355 F.2d 961, 965 (CCPA 1966). Although
`
`claims 18 and 29 of Chen refer to transmitting packets in the RUSH mode
`
`“as fast as possible,” the context provided by those claims refers explicitly to
`
`“ignoring the timing information” (emphasis added), and does not clearly
`
`relate to transmission speed. See also, e.g., Ex. 1002, col. 9, l. 48–col. 10, l.
`
`39 (discussing transmission modes in terms of determining timing of frame
`
`transmission); col. 10, ll. 40–50 (discussing transmission of lost packets “as
`
`soon as possible” (emphasis added)).
`
`Because of this deficiency, we conclude that Petitioner has not
`
`established a reasonable likelihood of prevailing on its challenge of
`
`independent claim 10 as anticipated by Chen, nor has it established a
`
`reasonable likelihood of prevailing on its challenges of claims that depend
`
`from claim 10, i.e., its challenges of claims 11, 13–16, and 18 as anticipated
`
`by Chen, of claim 17 as unpatentable under 35 U.S.C. § 103(a) over Chen
`
`and Willebeek, or of claim 12 as unpatentable under 35 U.S.C. § 103(a) over
`
`Chen and ISO-11172.2
`
`
`
`
`2 Similar to claim 10, independent claim 1 recites a server programmed “to
`send media data elements to the user system responsive to said requests, at a
`rate more rapid than the rate at which said streaming media is played back
`by a user,” and independent claim 24 recites sequential media data elements
`“from a server assumed to be capable of sending streaming media elements
`at a rate more rapid than the rate at which said streaming media is played
`back by a user.” Petitioner’s reasoning is similarly deficient with respect to
`these elements, and provides an independent basis for concluding that
`Petitioner has not established a reasonable likelihood of prevailing on its
`Chen-based challenges of claims 1–9 and 24–28.
`
`13
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`
`4. Claims 19–23
`
`Although Petitioner characterizes independent claim 19 as “of similar
`
`scope to claim 1,” it differs in important ways by omitting the limitations
`
`discussed above. See Pet. 41. The Petition’s analysis of claim 19 refers
`
`largely to its analysis of claims 1 and 10. Id. at 41–42.
`
`With respect to the preamble, Petitioner refers to its citation of
`
`drawings in Chen that disclose a server control that provides a stream buffer
`
`with data packets that include a “unique packet sequence number.” Id. at 42,
`
`32–38 (citing, inter alia, Ex. 1002, col. 9, ll. 7–20, col. 6, l. 55–col. 7, l. 2).
`
`Petitioner supports its contention that a person of ordinary skill in the art
`
`“would understand that the server instructions in Chen [used to create and
`
`prepare packets of data for transmission from the server to the client] are
`
`embodied on a non-transitory machine-readable medium” with testimony by
`
`Nathaniel Polish, Ph.D. Id. at 41 (citing Ex. 1005 ¶ 44).
`
`With respect to the body of the claim, Petitioner refers to this same
`
`analysis in contending that Chen discloses “said program recorded on said
`
`non-transitory machine readable medium comprising a routine to store and
`
`serially identify sequential data elements comprising said streaming media
`
`content, in a format capable of being served to users by said server.” Id. at
`
`42. Petitioner’s further identification of a transmission scheduler that
`
`maintains the stream buffer and schedules the data execution path is
`
`sufficient to support its contention that Chen discloses that the data elements
`
`are stored “in a format capable of being served to users.” Id. at 41 (citing
`
`Ex. 1002, col. 9, ll. 2–30, claims 10, 11, 16, 20, 27, 31, 42). Petitioner also
`
`supports its contention that Chen discloses the server responding to user
`
`requests for media data elements identified by a serial identifier with
`
`14
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`reference to a client controller that sends a command packet to request
`
`specific data packets. Id. at 42, 43 (citing Ex. 1002, col. 5, ll. 59–67; Ex.
`
`1005 ¶¶ 59–60). We conclude that Petitioner makes a sufficient showing at
`
`this stage, and that Petitioner sufficiently identifies disclosure in Chen for
`
`claims 20 and 23, which respectively recite that the streaming media content
`
`is obtained from a computer disk file and is encoded at a variable bit rate.
`
`Id. at 43, 44.
`
`We have considered, but are not persuaded by, Patent Owner’s
`
`contention that “Chen’s server does not respond to repeated ‘user requests
`
`for media data elements identified by a serial number’ [because] the
`
`lost/missing packet mechanism is only triggered for particular packets.”
`
`Prelim. Resp. 11. This argument is not commensurate with the scope of the
`
`claim, which does not refer to “repeated” user requests.
`
`With respect to claim 21, which recites that the server obtain
`
`streaming media from a live source, Petitioner contends that “[i]t would
`
`have been obvious to combine Willebeek’s teachings of a live capture
`
`station and circular buffer queue with Chen so that Chen could provide live
`
`video.” Id. at 46 (citing Ex. 1005 ¶ 48). Willebeek describes the Bamba
`
`audio and video streaming system, similarly using buffers at a server and
`
`client, and packetized data. Ex. 1004, 269, 273–274. Petitioner sufficiently
`
`supports its contention that the combination would achieve predictable
`
`results of a known technique to improve similar known devices with the
`
`testimony of Dr. Polish. Id. at 46–47 (citing Ex. 1005 ¶ 48). We have
`
`considered Patent Owner’s counterarguments against making the
`
`combination, including that “[t]he proposed combination would change the
`
`principle of operation of Chen,” but are not persuaded by them on the
`
`15
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`present record. Prelim. Resp. 13–14; see id. at 16–17. In addressing claim
`
`21, Petitioner relies on Willebeek for a limited purpose and “it is not
`
`necessary that the inventions of the references be physically combinable to
`
`render obvious the invention under review.” In re Sneed, 710 F.2d 1544,
`
`1550 (Fed. Cir. 1983) (citing Orthopedic Equip. Co. v. U.S., 702 F.2d 1005,
`
`1013 (Fed. Cir. 1983); In re Andersen, 391 F.2d 953, 958 (CCPA 1968); see
`
`also In re Nievelt, 482 F.2d 965, 968 (CCPA 1973) (“Combining the
`
`teachings of references does not involve an ability to combine their specific
`
`structures.”); KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007) (“[I]f a
`
`technique has been used to improve one device, and a person of ordinary
`
`skill in the art would recognize that it would improve similar devices in the
`
`same way, using the technique is obvious unless its actual application is
`
`beyond his or her skill.”).
`
`With respect to claim 22, which recites that the streaming media
`
`content is encoded at a constant bit rate, Petitioner observes that Chen
`
`discloses the MPEG-1 standard for providing the building blocks of the
`
`multimedia data stream and cites ISO-11172 as a description of that standard
`
`with both a constant bit rate and a variable rate. Pet. 67, 68. Patent Owner
`
`does not challenge the combination proposed by Petitioner, but instead
`
`asserts that “ISO-11172 does nothing to cure the deficiencies of Chen” with
`
`respect to limitations of underlying independent claim 19. Prelim. Resp. 24.
`
`On the current record, we are persuaded that Petitioner makes a sufficient
`
`showing.
`
`We conclude that Petitioner has demonstrated a reasonable likelihood
`
`of prevailing on its challenge of claims 19, 20, and 23 as anticipated under
`
`35 U.S.C. § 102(b) by Chen, on its challenge of claim 21 as unpatentable
`
`16
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`under 35 U.S.C. § 103(a) over Chen and Willebeek, and on its challenge of
`
`claim 22 as unpatentable under 35 U.S.C. § 103(a) over Chen and ISO-
`
`11172.
`
`
`
`C. Grounds Based on Carmel
`
`Petitioner challenges claims 10, 11, 13–21, and 23 as anticipated
`
`under 35 U.S.C. §§ 102(a) and 102(e) over Carmel; challenges claims 1, 2,
`
`4–9, 15, 24, 26, and 27 as unpatentable under 35 U.S.C. § 103(a) over
`
`Carmel and Willebeek; challenges claims 3 and 25 as unpatentable under 35
`
`U.S.C. § 103(a) over Carmel, Willebeek, and ISO-11172; and challenges
`
`claims 12 and 22 as unpatentable under 35 U.S.C. § 103(a) over Carmel and
`
`ISO-11172. Pet. 50–66, 68.
`
`
`
`1. Overview of Carmel
`
`Carmel describes a method for streaming live or prerecorded media
`
`from a server to multiple client computers over the Internet. Ex. 1003,
`
`col. 2, ll. 1–21. Figure 3A of Carmel is reproduced below.
`
`Figure 3A is a block diagram that schematically illustrates a data structure of
`
`a stream of broadcast data. Id. at col. 7, ll. 18–22. Data stream 40
`
`
`
`17
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`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. Id. at col. 7, ll. 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 col. 7, ll. 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 col. 7, ll. 59–64. Each
`
`time a new file is uploaded, the slide ID is updated. Id. at col. 7, ll. 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. Id. at col. 8, ll. 1–7. For example, a user interface
`
`graphic “slider” may be displayed to computer users, allowing individual
`
`users to select the starting point of the streamed media. Id. at col. 8, ll. 17–
`
`31.
`
`
`
`2. Claims 1–9 and 24–28
`
`Petitioner’s analysis of independent claims 1 and 24 relies on Carmel
`
`for all limitations except for claim 1’s recitation of software programmed “to
`
`transmit requests to the server to send one or more data elements . . . as said
`
`media player requires in order to maintain a sufficient number of media data
`
`elements in the media player for uninterrupted playback” and claim 24’s
`
`similar recitation of “a routine that requests transmission of the next
`
`sequential media data elements following said last sequential media data
`
`18
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`element, as said media player requires in order to maintain a sufficient
`
`number of media data elements in the media player for uninterrupted
`
`playback.” Pet. 50–62; see id. at 65. For these limitations, Petitioner relies
`
`on the teachings of Willebeek, which discloses preloading data at the client
`
`to ensure uninterrupted playback:
`
`the Bamba player (client software) at the receiving client
`automatically calculates how much data to preload in order to
`maintain continuous playback. This allows clients connected via
`low-bit-rate connections to fall back to a download-and-play
`mode and still receive the higher-bit-rate content.
`
`Ex. 1004, 270. Petitioner contends that it “would have been obvious to use
`
`Willebeek’s teaching of preloading and storing data at the client with the
`
`system disclosed in Carmel to provide the benefit of ensuring continuous
`
`playback even when network congestion delayed packet transmission.” Pet.
`
`51.
`
`We are not persuaded by Petitioner’s argument because it gives
`
`insufficient weight to the claim requirement that requests for transmission of
`
`media data elements be “as said media player requires” to provide
`
`uninterrupted playback. Willebeek’s disclosure of preloading at the client is
`
`part of an initialization phase that precedes playback, rather than an active
`
`procedure that occurs “as said media player requires.” See Ex. 1004, 270
`
`(“If the network conditions are suitable (sufficient sustained bandwidth is
`
`available), this file, streaming across the network, is played at the client
`
`immediately. Otherwise the file is played once uninterrupted playback can
`
`be ensured.” (Emphasis added)).
`
`Because of this deficiency, we conclude that Petitioner has not
`
`demonstrated a reasonable likelihood of prevailing on its challenge of
`
`19
`
`
`
`IPR2016-01238
`Patent 8,122,141 B2
`
`independent claims 1 and 24 as unpatentable under 35 U.S.C. § 103(a) over
`
`Carmel and Willebeek, nor has it established a reasonable likelihood of
`
`prevailing on its challenges of claims that depend from claims 1 and 24, i.e.,
`
`its challenges of claims 2, 4–9, and 26–28 as unpatentable under 35 U.S.C.
`
`§ 103(a) over Carmel and Willebeek, or of claims 3 and 25 as unpatentable
`
`under 35 U.S.C. § 103(a) over Carmel, Willebeek, and ISO-11172.
`
`
`
`3. Claims 10–23
`
`Petitioner’s analysis of claims 10–23 largely refers to its analysis of
`
`claims 1–9, observing that neither independent claim 10 nor independent
`
`claim 19 recites the limitation for which it relies on Willebeek. Pet. 65–66,
`
`68. We have reviewed that analysis as presented in its claim chart at pages
`
`52–61 of the Petition, and as it applies to independent claims 10 and 19, and
`
`are persuaded that Petitioner makes a sufficient showing at this stage.
`
`Specifically, Petitioner draws a correspondence between the “serial
`
`identifiers” recited in the claims and the indexes used by Carmel to identify
`
`media slices, which function as “sequential media data elements,” and
`
`between “requests from the user system for one or more media data elements
`
`specifying the identifiers of the requested data elements” and Carmel’s
`
`“slider” functionality. Id. at 53–56.
`
`With re