Trials@uspto.gov
`571.272.7822
`
`
`
`
`
`
`
`
`
`
` Paper No. 21
` Filed: December 26, 2017
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`WEBPOWER, INC.,
`
`
`FRIENDFINDER NETWORKS INC., STREAMRAY INC., WMM, LLC,
`WMM HOLDINGS, LLC, and MULTI MEDIA, LLC,
`
`DUODECAD IT SERVICES LUXEMBOURG S.A.R.L., ACCRETIVE
`TECHNOLOGY GROUP, INC., ICF TECHNOLOGY, INC., and
`RISER APPS LLC,
`Petitioner,
`
`v.
`
`WAG ACQUISITION, LLC,
`Patent Owner.
`_______________
`
`Case IPR2016-01239
`Patent 8,364,839 B2
`____________
`
`
`Before TREVOR M. JEFFERSON, BRIAN J. McNAMARA, and
`PATRICK M. BOUCHER, Administrative Patent Judges.
`
`JEFFERSON, Administrative Patent Judge.
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`571.272.7822
`
`
`
`
`
`
`
`
`
`
` Paper No. 21
` Filed: December 26, 2017
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`WEBPOWER, INC.,
`
`
`FRIENDFINDER NETWORKS INC., STREAMRAY INC., WMM, LLC,
`WMM HOLDINGS, LLC, and MULTI MEDIA, LLC,
`
`DUODECAD IT SERVICES LUXEMBOURG S.A.R.L., ACCRETIVE
`TECHNOLOGY GROUP, INC., ICF TECHNOLOGY, INC., and
`RISER APPS LLC,
`Petitioner,
`
`v.
`
`WAG ACQUISITION, LLC,
`Patent Owner.
`_______________
`
`Case IPR2016-01239
`Patent 8,364,839 B2
`____________
`
`
`Before TREVOR M. JEFFERSON, BRIAN J. McNAMARA, and
`PATRICK M. BOUCHER, Administrative Patent Judges.
`
`JEFFERSON, Administrative Patent Judge.
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`
`INTRODUCTION
`I.
`On December 27, 2016, we instituted inter partes review based upon
`the ground asserted in the Petition (Paper 2, “Pet.”) by Webpower, Inc.,
`challenging claims 5, 12, and 19 of U.S. Patent No. 8,364,839 B2 (Ex. 1001,
`“the ’839 patent”) and a Preliminary Response to the Petition (Paper 6,
`“Prelim. Resp.”) filed by WAG Acquisition, LLC (“WAG” or “Patent
`Owner”). Paper 7 (“Dec.”) 35–36. We subsequently joined Friendfinder
`Networks Inc., Streamray Inc., WMM, LLC, WMM Holdings, LLC, and
`Multi Media, LLC in IPR2017-00784; and Duodecad IT Services
`Luxembourg S.A.R.L., Accretive Technology Group, Inc., ICF Technology,
`Inc., and Riser Apps LLC in IPR2017-00785 as parties to the present
`proceeding. Papers 11, 12. We refer collectively to all petitioners herein as
`“Petitioner.”
`In our Decision, we instituted inter partes review on the ground that
`claims 5, 12, and 19 of the ’839 patent are unpatentable under 35 U.S.C.
`§ 103(a) over (1) Chen,1 Willebeek,2 and Chen FH;3 and (2) Chen, Cannon,4
`and Chen FH. Dec. 36; see Pet. 5 (setting forth grounds).
`Following institution, Patent Owner filed a Patent Owner’s Response
`(Paper 10, “PO Resp.”) and Petitioner filed a Consolidated Reply to Patent
`Owner’s Response (Paper 14, “Reply”). We held a hearing on September
`
`1 U.S. Patent 5,822,524, issued October 13, 1998 (Ex. 1004, “Chen”).
`2 M. H. Willebeek-LeMair, et al., Bamba-Audio and Video Streaming Over
`the Internet, IBM J. RES. DEVELOP., Vol. 42, No. 2 (1998) (Ex. 1008,
`“Willebeek”).
`3 File History of U.S. Application 505,488 (Ex. 1010, “Chen FH”).
`4 U.S. Patent 6,014,706, issued Jan. 11, 2000 (Ex. 1009, “Cannon”).
`2
`
`
`
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`25, 2017, and a transcript of the hearing is included in the record. Paper 20
`(“Tr.”).
`We have jurisdiction under 35 U.S.C. § 6. This Final Written
`Decision is entered pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73.
`For the reasons discussed below, Petitioner has shown by a preponderance
`of the evidence that the challenged claims are unpatentable.
`
`A. Related Proceedings
`The ’839 patent is the same patent that was the subject of inter partes
`review in IPR2015-01036 (“the ’1036 IPR”), where our Final Written
`Decision determined that claims 1, 4, 6, 8, 11, 13, 15, 18, and 20 are
`unpatentable under 35 U.S.C. § 103(a) as obvious over Chen and Chen FH;
`and that claims 3, 10, and 17 are unpatentable under 35 U.S.C. § 103(a) as
`obvious over Chen, Chen FH, and ISO-11172.5 Duodecad IT Services
`Luxembourg S.a.r.l. v. WAG Acquisition, LLC, IPR2015-01036 (PTAB Oct.
`20, 2016) (Paper 17) (“Duodecad-01036”). We also note that the ’839
`patent is at issue in I.M.L. SLU et al v. WAG Acquisition, LLC, IPR2016-
`01658.
`
`
`5 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,” August 1993; 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 2: Video,” August 1993; and 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 3:
`Audio,” August 1993 (collectively “ISO-11172”).
`3
`
`
`
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`
`The parties state that the ’839 patent is asserted in nine pending
`litigations: WAG Acquisition, LLC v. Sobonito Investments, Ltd. et al., Case
`No. 2:14-cv-1661-ES-MAH (D.N.J.); WAG Acquisition, LLC v. Multi
`Media, LLC et al., Case No. 2:14-cv-2340-ES-JAD (D.N.J.); WAG
`Acquisition, LLC v. Data Conversions, Inc. et al., Case No. 2:14-cv-2345-
`ES-MAH (D.N.J.); WAG Acquisition, LLC v. Flying Crocodile, Inc. et al.,
`Case No. 2:14-cv-2674-ES-MAH (D.N.J.); WAG Acquisition, LLC v.
`Gattyàn Group S.à r.l. et al., Case No. 2:14-cv-2832-ES-MAH (D.N.J.);
`WAG Acquisition, LLC v. FriendFinder Networks Inc. et al., Case No. 2:14-
`cv-3456-ES-MAH (D.N.J.); WAG Acquisition, LLC v. Vubeology, Inc. et al.,
`Case No. 2:14-cv-4531-ES-MAH (D.N.J.); WAG Acquisition, LLC v.
`Gamelink Int’l Ltd. et al., Case No. 2:15-cv-3416-ES-MAH (D.N.J.); WAG
`Acquisition LLC v. WebPower, Inc. et al., Case No. 2:15-cv-03581-ES-
`MAH (D.N.J). Pet. 1–2; Paper 4. One related litigation, WAG Acquisition,
`LLC v. MFCXY, Inc. et al., Case No. 2:14-cv-3196-ES-MAH (D.N.J.), has
`been dismissed. Pet. 1–2; Paper 4.
`
`B. The ʼ839 Patent (Ex. 1001)
`The ’839 patent, titled “Streaming Media Delivery System,” issued on
`January 29, 2013. It describes users viewing or listening to streaming
`content over Internet connections who encounter interruptions (“drops outs”)
`due to transmission delays and losses. Ex. 1001, 2:16–23. The ’839 patent
`addresses a “need for improved systems and methods for delivering
`streaming content over the Internet or other communications medium, which
`facilitate continuous transmission of streaming content, respond on demand
`
`
`
`
`4
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`without objectionable buffering delay, and perform without disruption or
`dropouts.” Id. at 3:24–29.
`The ’839 patent states that Internet streaming, as practiced in the prior
`art, relied on a server transmitting streaming media continuously at the
`playback rate of the media, where the playback rate corresponds to the
`number of frames-per-second at which the media was encoded for playback
`at normal speed. Id. at 1:30–2:15. Data in each frame can be encoded using
`Constant Bit Rate (CBR) or Variable Bit Rate (VBR) encoding. Id.
`A client device for receiving and playing a streamed transmission
`(e.g., a computer running media player software) typically used a playback
`buffer (user buffer) for collecting frames of data being streamed. The client
`would not begin playback until the user buffer was filled to a specified level.
`The user buffer thus provided a reservoir of data available in the event of
`packet loss or delay, corresponding to the playback time of the amount of
`media initially buffered. If losses or delays occurred during transmission,
`the content of the user buffer (reservoir of data) would shrink as playback
`continued during the period of such losses or delays. See, e.g., Ex. 1001,
`2:16−38. Because playback continued at the playback rate, the buffer did
`not refill after depletion, other than by suspending playback and waiting for
`it to refill. Startup of playback always had to wait for the user buffer
`initially to accumulate data to a specified level, which required a noticeable
`startup delay.
`
`
`
`
`5
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`
`Figure 1 of the ’839 patent is reproduced below.
`
`
`Figure 1 is a schematic diagram that illustrates elements of a
`streaming media buffering system. Id. at 4:1–3. Figure 1 shows server 12 is
`connected to Internet 10 for transmitting sequenced streaming-media data
`elements, composed a plurality of time-sequenced data elements. Id. at 6:7–
`14. Associated with server 12 are buffer manager 16 and server buffer 14,
`which stores at least one of the data elements for transmission. Id. at 6:14—
`17. In one embodiment, buffer manager 16 receives the media data, supplies
`the media data in order to first-in–first-out (“FIFO”) buffer 14, and
`maintains pointers 24a–24n into the buffer for each user computer,
`indicating the last media data element that has been sent to a respective user
`6
`
`
`
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`and thus indicating the next element or elements to be sent. Id. at 6:61–7:6.
`Once FIFO buffer 14 is full, the oldest data elements in the buffer are
`deleted as new elements are received. Id. at 7:1–10. A predetermined
`number of data elements are kept in FIFO buffer 14. Id.
`The server buffer is pre-filled before a user joins the stream and
`transmission starts. Id. at 8:31–44. Pre-filling of the server buffer can be
`rapid if the data comes from disk storage. If joining a live (real time)
`transmission in progress, the server buffer is already filled at the time the
`user joins the stream. Once the server buffer is sufficiently full, the server
`buffer sends its contents, as fast as the connection will support, to the user
`system, to rapidly fill the “user buffer” (the playback buffer at the client).
`The user system can then start playing almost instantaneously. Id.
`For real-time data sources, such as a radio station, the ’839 patent
`describes that “server buffer 14 might be set to hold (for example) 30
`seconds of media data.” Id. at 7:26–29. “The server buffer 14 is filled the
`first time the media source connection is established.” Id. at 7:43–44.
`“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 7:48–50.
`Specifically, the ’839 patent states:
`Once a connection is made to a user’s computer (e.g., user
`computer 18), server 12 sends the media data to the user
`computer in the following manner. First, media data is sent 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 (referred to herein as a
`7
`
`
`
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`
`“higher than playback” rate), until the predetermined amount of
`data that had been stored in the server buffer has been transferred
`to the user’s computer. Once the contents of server buffer 14 has
`been transferred, a steady state condition is reached Wherein as
`each media data element arrives at server 12, it is immediately
`sent out to the user computer.
`Id. at 7:53–65. If there are no interruptions in the transmission, during “this
`steady state condition, the media data is sent at a rate that matches the
`constant fill rate of the server buffer, and is received at the same rate by the
`user computer.” Id. at 7:66–8:1
`The ’839 patent further states:
`With the present invention, as soon as a user connects to the
`server 12, the server 12 transmits audio/video data as sequential
`data elements from its buffer 14 to the buffer 20 of the user, at a
`higher than playback rate. Unlike the prior art, media begins to
`play on the user computer 18 as soon as the user connection is
`made to the audio server 12 and a minimal amount of data
`elements have been received and stored in the user’s buffer 20.
`The user’s buffer 20 is built up while the media is playing. As
`each data element is played, it is deleted or displaced from the
`user’s buffer 20.
`Id. at 9:8–17. The ’839 patent’s approach uses the server’s built-in transport
`mechanism, e.g., the server’s TCP stack, as a control mechanism. Id. at 8:9–
`13. The server buffer sends data, via the transport mechanism, to the user
`buffer. At any time, the connection between the server and user buffers, as
`moderated by the server’s transport mechanism, sends as much data as the
`transport mechanism will accept, and sends the data as fast as the connection
`will allow. Id. at 10:24–33.
`During steady state, Transmission Control Protocol (TCP) senses if a
`transmission interruption or delay occurs and temporarily stops accepting
`8
`
`
`
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`data, causing data to “back up” in the server buffer and correspondingly to
`deplete in the user buffer. Id. at 8:4–8. When the interruption or delay
`clears, the “backed up” data is sent to the client side as fast as the connection
`will support, emptying the accumulated data in the server buffer, restoring
`the user buffer, and resuming the steady state operation. Id. at 10:24–33.
`
`C. Illustrative Claims
`Dependent claims 5, 12, and 19 are the challenged claims. Dependent
`claim 5 and independent claim 1, from which claim 5 depends, are
`illustrative and reproduced below (Ex. 1001, 15:57–16:25, 16:34–35):
`1. A method for distributing streaming media via the Interact [sic]
`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 encoded for
`playback at a playback rate, the user system being assumed to
`have a user buffer for receiving media data and facilities to play
`back the streaming media at the playback rate for viewing or
`listening by said at least one user, from a server having a server
`buffer for buffering sequential media data elements, said
`method comprising:
`loading the server buffer with streaming media data elements;
`sending an initial amount of streaming media data elements to the
`user system at an initial sending rate more rapid than the
`playback rate; and
`thereafter, sending further streaming media data elements to the
`user system at about the playback rate and filling the server
`buffer or moving a data window through the server buffer at
`about the playback rate;
`wherein the initial amount of streaming media data elements, and
`the initial sending rate, are sufficient for the user system to
`begin playing back the streaming media while the user buffer
`continues to fill;
`
`
`
`
`9
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`
`wherein the further streaming media data elements are received at
`about the playback rate by the user system if there are no
`interruptions in the transmission of streaming media data
`elements between the server and the user system; and
`wherein said method further comprises detecting if any
`interruptions in the transmission of streaming media data
`elements between the server and the user system have
`occurred such that streaming media data elements that
`have been sent by the server to the user system have been
`delayed or not received by the user system.
`
`5. The method of claim 1, wherein the media data elements
`are provided from a live broadcast.
`
`II. ANALYSIS
`A. Claim Interpretation
`We interpret claims of an unexpired patent using the broadest
`reasonable interpretation in light of the specification of the patent in which
`they appear. See 37 C.F.R. § 42.100(b); see also Cuozzo Speed Techs., LLC
`v. Lee, 136 S. Ct. 2131, 2144–46 (2016) (upholding the use of the broadest
`reasonable interpretation standard as the claim construction standard to be
`applied in an inter partes review proceeding). Under the broadest
`reasonable interpretation standard, claim terms are generally given their
`ordinary and customary meaning, as would be understood by one of ordinary
`skill in the art, in the context of the entire disclosure. In re Translogic Tech.
`Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007).
`In IPR2015-01036, our Final Written Decision adopted our
`preliminary constructions of the following claim terms/phrases from the
`’839 patent: “playback rate,” “at about the playback rate,” “the initial
`
`
`
`
`10
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`amount of streaming media data elements, and the initial sending rate, are
`sufficient for the user system to begin playing back the streaming media
`while the user buffer continues to fill,” “sending to the user system [the]
`unsent streaming media elements in the server buffer at a sending rate more
`rapid than the playback rate,” and “provided from a live broadcast,” and “for
`each of the plurality of user systems, maintaining a record of the last
`streaming media data element that had been sent to the user system.”
`Duodecad-01036 at 9. We adopted those constructions summarized below
`in our Decision to Institute in the present case (Dec. 9–10).
`Claim Term/Phrase
`Construction
`“playback rate”
`“A data rate for which the data is
`encoded to be played out.”
`“at approximately the rate at which
`the media will be played out”
`“Enough data is initially sent fast
`enough so that the player can at
`least start playback while its buffer
`continues to fill.”
`
`“at about the playback rate”
`
`“At least some of the unsent data in
`the server buffer is sent at a
`sending rate more rapid than the
`playback rate.”
`
`“Live describes something being
`contemporaneously created and
`streamed.”
`
`
`
`“the initial amount of streaming
`media data elements, and the
`initial sending rate, are sufficient
`for the user system to begin
`playing back the streaming media
`while the user buffer continues to
`fill”
`
`“sending to the user system [the]
`unsent streaming media elements
`in the server buffer at a sending
`rate more rapid than the playback
`rate”
`“provided from a live broadcast;”
`and “for each of the plurality of
`user systems, maintaining a record
`of the last streaming media data
`element that had been sent to the
`user system”
`
`
`
`
`
`11
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`Dec. 10 (citing IPR2015-01036, Paper 8).
`The parties have not further argued claim construction and we hereby
`adopt our preliminary constructions as final.
`
`B. Principles of Law
`A claim is unpatentable under § 103(a) if the differences between the
`claimed subject matter and the prior art are such that the subject matter, as a
`whole, would have been obvious at the time the invention was made to a
`person having ordinary skill in the art to which said subject matter pertains.
`KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007). The question of
`obviousness is resolved on the basis of underlying factual determinations,
`including (1) the scope and content of the prior art; (2) any differences
`between the claimed subject matter and the prior art; (3) the level of skill in
`the art; and (4) when in evidence, objective indicia of non-obviousness
`(i.e., secondary considerations). Graham v. John Deere Co., 383 U.S. 1, 17–
`18 (1966). We analyze this asserted ground based on obviousness with the
`principles identified above in mind.
`
`C. Level of Skill in the Art
`Petitioner’s declarant, Nathaniel Polish, Ph.D., asserts that a person of
`ordinary skill in the art “would have had a B.S. degree in computer science
`or electrical engineering (or comparable degree) and two years of experience
`in networking or streaming media, or a M.S. in computer science or
`electrical engineering (or comparable degree).” Ex. 1003 ¶ 21. Dr. Polish
`further states that “[t]hese descriptions are approximate, and a higher level
`
`
`
`
`12
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`of education or specific skill might make up for less experience, and vice-
`versa.” Id. ¶ 22.
`Neither Patent Owner nor its declarant, Mung Chiang, Ph.D., proffers
`a characterization of the education and experience of a person of ordinary
`skill, although Dr. Chiang attests that his own qualifications permit him to
`provide an opinion, “including what a person having ordinary skill in the art
`would have understood.” Ex. 2001 ¶ 10.
`We find Dr. Polish’s statement of the level of ordinary skill in the art
`reasonable, and adopt it for this Final Written Decision.
`
`D. Prior Art Asserted
`1. Chen (Ex. 1004)
`Chen describes a system for the “just-in-time” retrieval of multimedia
`files over a computer network. Ex. 1004, [54]. Figure 1 of Chen is
`reproduced below.
`
`
`Figure 1 is a schematic illustration showing client machine 20 receiving data
`streamed from server machine 21 over a network. Data packets are loaded
`into a “server control stream buffer” 1 for streaming over data channel 6.
`13
`
`
`
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`Streamed packets are accumulated in “client agent packet buffer” 31 for
`playback. Id. at 4:21, 4:65−5:44, Figure 1.
`Chen describes “normal,” “rush,” and “pause” transmission modes for
`streaming from a server to a user. Id. at 6:1−15 (emphasis omitted). It
`describes a “water mark” model for buffering streaming content. Id. at
`6:16−54 (emphasis omitted). The server buffer is like a water bucket
`having high and low “water marks.” Id. Water exits the bucket through a
`spout similar to data exiting a packet buffer as its content is delivered to a
`user. Id. When water in the bucket is at a level between the water marks,
`transmission occurs in the normal mode. Id. The normal mode carries out
`frame level pacing, i.e., transmission at the playback rate. Id. at 10:3−4.
`When the amount of data falls below the low mark, the transmission mode
`changes to “rush.” Id. at 6:42−47 (emphasis omitted). In rush mode, frame
`level pacing is ignored and data is transmitted as fast as possible. Id. at
`claims 18, 29; Figure 6.
`
`2. Chen FH (Ex. 1010)
`Chen FH shows that during prosecution of the application eventually
`issuing as Chen, patent applicant submitted a Declaration in accordance with
`37 C.F.R. § 1.131 for the purpose of predating (“swearing behind”) a cited
`reference. Ex. 1010, 77−79. That Declaration references a “Quick Video
`Server” (“QVS Sever”) exhibit document alleged to describe a commercial
`embodiment of Chen. Id. at 77. The Declaration includes a claim chart
`mapping the technical documents provided for the QVS server to the then-
`pending claims. Id. at 112–119. Chen FH describes a protocol used by the
`QVS server and is reproduced below.
`14
`
`
`
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`
`
`Id. at 86. The QVS Server Protocol describes “PAUSE,” “NORMAL,” and
`“RUSH” transmission modes. Id. Rush mode is described as “transmit data
`as fast as possible, subject to the Round-Robin sharing with other active
`streams.” Id.
`
`3. Willebeek (Ex. 1008)
`Willebeek describes a method of displaying streamed digital video
`data, including live video, on a client computer using buffers as the client
`and server. Ex. 1008, 269, FIGURE 6. Willebeek teaches that “[a] Live
`Bamba system was developed to stream audio and video from a live source
`15
`
`
`
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`across the Web to multiple recipients.” Id. at 277. Figure 6 of Willebeek is
`reproduced below.
`
`
`Willebeek Figure 6 is a schematic diagram of a “Live Bamba
`system” showing a circular buffer queue containing the most
`recent several seconds of a live transmission.
`Id. at 277. Willebeek states that “[t]he Live Bamba system consists of three
`primary components (as illustrated in Figure 6 [above]): an audio/video
`capture station, an audio/video reflector, and an audio/video playback
`station.” Id.
`In the capture station, audio and video inputs are converted from
`analog to digital form, compressed, and then packetized. The
`Live Bamba packets are transmitted to the reflector via TCP/IP
`connection that is established between the reflector and the
`
`
`
`
`16
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`
`capture station. The reflector then establishes and manages
`multiple connections to interested recipients.
`Id. at 277–278. When a new user requests live video, the server produces a
`new copy of the circular buffer and that copy is used as that user’s server
`buffer. Id.; see also Figures 6–7.
`4. Cannon (Ex. 1009)
`Cannon is an issued patent, filed March 14, 1997, describing a method
`of displaying streamed digital video data, including live video, on a client
`computer using buffers as the client and server. Ex. 1009, Abstract, Figure
`1A. Cannon is discussed in the background section of the ’839 patent, and
`was therefore before the Patent Office during original prosecution, but not
`considered in combination with Chen. Pet. 10.
`Cannon Figure 1A is reproduced below.
`
`
`
`
`
`
`17
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`
`Cannon Figure 1A is a schematic diagram of a video camera
`providing a live feed to an encoder. Figure 1A depicts that computer
`network 100 includes a server computer 102 and a client computer 104.
`Video camera 106 records video data, which is digitized and encoded by
`encoder 110 for transmission to either server 102 or memory 115 for storage.
`Encoder 110 represents, in one embodiment of the invention, the video
`source from which data may be streamed to the client via the server.
`Ex. 1009, 7:10–34. Encoder 110, which may be implemented in hardware
`or software, may also perform compression on the raw digital video data to
`improve storage and transmission efficiency. Data packets outputted by
`encoder 110 (or retrieved from memory 115) are then buffered within server
`play-out buffer 112 for transmission to client computer 104. Data packets
`stored in memory 115 may be employed by client computer 104 to facilitate
`rewind, fast forward, and other control modes. Id. As each data packet or
`group of data packets is outputted from server play-out buffer 112 onto data
`connection 114 for transmission (e.g., responsive to a command from client
`computer 104 which is received by server computer 102 via a control
`connection 116), the same data packet or group of data packets is input into
`retransmit buffer 118 at the server. Id. at 7:35–40.
`Retransmit buffer 118 represents a first-in-first-out (FIFO) buffer
`which retains for a limited time a data packet transmitted from server
`playout buffer 112. As new data packets are input into retransmit buffer 118,
`old data packets (starting with the oldest data packets) are discarded from
`transmit buffer 118. Id. at 7:46–65. As data packets are received by client
`computer 104 from data connection 114, they are inputted into client play-
`18
`
`
`
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`out buffer 120 to be displayed by renderer application 122. Client play-out
`buffer 120 may represent, in one embodiment, a FIFO buffer. Client play-
`out buffer 120 and/or server play-out buffer 112 are typically sized
`appropriately to minimize latency while taking into account the reliability
`and stability of network 100 through which data connection 114 traverses.
`Id. at 7:66–8:16.
`Although only one control connection 116 and one control connection
`114 are shown in FIGURE 1A, a real-time video session may involve
`multiple data and control connections for the multiple data streams, e.g.,
`video, audio, annotations, and the like. Id. at 8:28–8:37.
`
`E. Obviousness Based on Chen (Ex. 1004), Chen FH (Ex. 1010),
`and Willebeek (Ex. 1008)
`Petitioner contends that that Chen in combination with Chen FH
`teaches the limitations of independent claims 1, 8, and 15. Pet. 16–32, 35–
`44. Petitioner cites evidence and argument that the three transmission
`modes described in Chen (Normal, Rush, and Pause) in combination with
`Chen FH teaches the limitations of claims 1, 8, and 15. Id. at 16–32, 42–44
`(citing Ex. 1003 ¶¶ 36, 38, 40, 43, 51, 52, 54, 55, 56). Petitioner provides a
`claim chart with citations to Chen for the limitations of independent claims
`1, 8, and 15. Pet. 19–32.
`To the extent that Chen does not teach the limitation for “sending an
`initial amount of streaming media data elements to the user system at an
`initial sending rate more rapid than the playback rate” as recited in claim 1,
`Petitioner argues that Chen FH in combination with Chen teaches starting in
`RUSH mode upon opening of a multimedia file. Pet. 42–44 (citing Ex. 1003
`19
`
`
`
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`¶¶ 66–67; Ex. 1010, 77–79, 86–87). Petitioner provides an articulated
`reasoning for the combination of Chen and Chen FH, noting that
`combination would minimize start delay, and require combining teachings in
`a known way to achieve predictable results. Ex. 1003 ¶¶ 63–65; see also Ex.
`1013, 63:14–16. Finally, as Petitioner notes, our Final Written Decision in
`IPR2015-01036 determined that Chen and Chen FH rendered the limitations
`of claims 1, 8, and 15 obvious. Reply 1; Duodecad-01036 at 19–29, 30–35,
`43. Patent Owner did not appeal this decision. Accordingly, we determine
`that Chen and Chen FH teach the limitations of claims 1, 8, and 15 of the
`’839 patent.
` Dependent claims 5, 12, and 19, which depend from claims 1, 8, and
`15 respectively, require that the streaming content be generated from a live
`broadcast. Petitioner contends that claims 5, 12, and 19 are unpatentable as
`obvious in view of Chen and Willebeek. Pet. 35–39 (citing Ex. 1003).
`Petitioner argues that a modified version of the Willebeek circulating buffer
`could be used to feed a live broadcast to a modified version of the Chen
`server buffer. Pet. 37.
`Specifically, Petitioner notes that in a preferred Chen embodiment,
`shown in Figure 4, a parser 62 extracts frame-by-frame timing information
`from a multimedia file, placing the timing information in an index file 63,
`which is used by the server control 64 to pace transmission. Pet. 35 (citing
`Ex. 1004, 8:43–55). Chen states that the parser can extract the frame
`information beforehand or on the fly (during multimedia file transmission).
`Ex. 1004, 8:50–52. Petitioner contends that the Willebeek “capture station”
`packetizes data from a live stream. Pet. 36 (citing Ex. 1008, 277–278;
`20
`
`
`
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`Figure 6). These packets are transferred to a server buffer. Petitioner
`proposes that Willebeek’s plurality of buffers, instead of being fed to a
`playback station (see Ex. 1008, Figure 6) would instead be fed to Chen’s
`server control stream buffer, as shown in Petitioner’s combination figure,
`reproduced below.
`
`
`
`Pet. 37. Petitioner’s modified figure shows an arrangement where the
`circular buffer of Figure 6 from Willebeek replaces the server buffer from
`Figure 1 of Chen. Pet. 37–38 (citing Ex. 1003 ¶¶ 51–52). Petitioner
`presents evidence to support its contention that it 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 as well as
`prestored video. Pet. 36 (citing Ex. 1003 ¶ 51). Furthermore, Petitioner
`asserts that it would have been obvious to configure the combined system so
`that, if one of Chen’s users requested live video, a new copy of a circular
`buffer queue such as the one produced by Willebeek’s capture station and
`server would become Chen’s server buffer. Id. at 36–37 (citing Ex. 1003
`
`
`
`
`21
`
`
`
`IPR2016-01239
`Patent 8,364,839 B2
`
`¶ 52). Because the circular buffer queue contains a few seconds of video,
`Chen “would then be able to rush the first packets to the user.” Pet. 37.
`After that, the packets would be sent at the normal (playback rate), as they
`are received—packets would be received at the server as they are generated
`by the capture station from the live feed and, barring interruptions, would be
`passed to the client packet buffer 31 at the playback rate. Ex. 1004, 6:33–
`39.
`
`Petitioner argues Chen and Willebeek both utilize packet data and “it
`would have . . . been obvious to a POSITA to take Willebeek’s teachings to
`utilize a capture station to receive video, encode it into Chen-compliant
`packets, and place them in a reflector with a circular buffer queue” as
`Willebeek teaches. Pet. 39 (citing Ex. 1003 ¶ 54). Petitioner argues:
`A [person of ordinary skill in the art] would have been motivated
`to combine the teachings in this manner because, as Willebeek
`describes: “Most recently, streamed audio and video have
`become available from both stored and live sources on the Web.”
`Ex. 1008 at 277; Polish Decl., Ex. 1003 at ¶ 56. Modifying Chen
`in this manner would allow the system to provide access to this
`recently available data source.
`Pet. 39.
`We have reviewed Petitioner’s arguments and evidence with respect
`to dependent claims 5, 12, and 19, and the claims from which they depend,
`and conclude that Petitioner de
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
