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

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