UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`I.M.L. SLU
`
`Petitioner
`
`v.
`
`WAG ACQUISITION, LLC
`
`Patent Owner
`
`
`
`Patent No. 8,364,839
`
`Issue Date: January 29, 2013
`
`Title: STREAMING MEDIA DELIVERY SYSTEM
`
`
`
`PETITION FOR INTER PARTES REVIEW
`
`UNDER 35 U.S.C. §§ 311-319 AND 37 C.F.R. § 42.100 ET SEQ.
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`
`EXHIBIT LIST
`
`Exhibit Number Description
`1001
`U.S. Patent No. 8,364,839 to Price (the “’839 Patent”)
`
`1002
`
`1003
`
`1004
`
`1005
`
`1006
`
`1007
`
`1008
`
`1009
`
`1010
`
`1011
`
`1012
`
`U.S. Patent No. 5,822,524 to Chen et al. (“Chen”)
`
`File History of U.S. Patent No. 5,822,524 to Chen et al.
`("Chen File History”)
`Willebeek-LeMair, et al., “Bamba – Audio and Video
`Streaming Over the Internet,” IBM Journal of
`Research and Development¸ Vol. 42, No. 2, March
`1998 (“Willebeek”)
`U.S. Patent No. 6,389,473 to Carmel et al.
`(“Carmel”)
`Declaration of Dr. Gareth Loy in Support of Inter Partes
`Review of U.S. Patent 8,364,839
`Curriculum Vitae of Dr. Gareth Loy
`
`Prosecution history for U.S. Patent No. 8,364,839
`
`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 (“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,” August 1993 (“ISO-11172-2”)
`
`International Standard ISO/IEC 11172-3, “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 (“ISO-11172-3”)
`Petitioner’s Waiver of Service
`
`
`
`i
`
`

`
`
`
`Table of Contents
`
`Page
`
`
`REQUESTED RELIEF ................................................................................... 1
`I.
`II. MANDATORY NOTICES ............................................................................. 1
`A.
`Real Parties-in-Interest .......................................................................... 1
`B.
`Related Matters ...................................................................................... 1
`C.
`Counsel and Service Information .......................................................... 4
`III. CERTIFICATION OF GROUNDS FOR STANDING .................................. 5
`IV. STATEMENT OF PRECISE RELIEF REQUESTED ................................... 5
`THRESHOLD REQUIREMENT FOR INTER PARTES REVIEW ............... 6
`V.
`A.
`Reasonable Likelihood of Invalidity ..................................................... 6
`B.
`Review Is Appropriate In View Of Prior IPRs ..................................... 7
`VI. OVERVIEW OF THE ’839 PATENT AND ADMITTED PRIOR ART ....... 8
`VII. OVERVIEW OF THE NEWLY APPLIED PRIOR ART ............................ 12
`A.
`Chen ..................................................................................................... 12
`B.
`Chen File History ................................................................................ 20
`C. Willebeek ............................................................................................. 21
`D.
`Carmel ................................................................................................. 24
`E.
`ISO-11172 (Parts 1-3) ......................................................................... 26
`VIII. CLAIM CONSTRUCTION .......................................................................... 27
`A.
`Independent Claims Preambles ........................................................... 27
`B.
`Prior Constructions .............................................................................. 27
`IX. LEVEL OF ORDINARY SKILL IN THE ART ........................................... 29
`X.
`EXPLANATION OF GROUNDS FOR UNPATENTABILITY ................. 29
`A. Ground 1: Claims 1-2, 4, 6-9, 11, 13-16, 18 And 20-21 Are
`Obvious Over Chen In View Of Chen File History ............................ 29
`Claims 1, 8 and 15 ..................................................................... 29
`1.
`2.
`Claims 2, 9 and 16..................................................................... 55
`
`ii
`
`
`
`

`
`
`
`
`
`
`Table of Contents
`(continued)
`
`Page
`
`Claims 4, 11 and 18 ................................................................... 56
`3.
`Claims 6, 13 and 20 ................................................................... 56
`4.
`Claims 7, 14 and 21 .................................................................. 56
`5.
`B. Ground 2: Claims 3, 10 and 17 Are Obvious Over Chen In View
`Of Chen File History and ISO-11172 ................................................. 57
`C. Ground 3: Claims 5, 12 and 19 Are Obvious Over Chen In View
`Of Chen File History and Willebeek ................................................... 59
`D. Ground 4: Claims 5, 12 and 19 Are Obvious Over Chen In View
`Of Chen File History and Carmel ....................................................... 61
`XI. CONCLUSION AND STATEMENT OF PRECISE RELIEF
`REQUESTED ................................................................................................ 62
`
`
`
`
`
`iii
`
`

`
`I.
`
`REQUESTED RELIEF
`I.M.L. SLU (“Petitioner”) petitions for Inter Partes Review (“IPR”) under
`
`35 U.S.C. §§ 311-319 and 37 C.F.R. § 42 et seq. of claims 1-21 of U.S. Patent No.
`
`8,364,839 (Ex. 1001), assigned to WAG Acquisition, LLC (“Patent Owner”).
`
`Petitioner challenges the patentability of claims 1-21 of the ‘839 Patent under 35
`
`U.S.C. §103, and requests that an IPR be instituted and a final determination of the
`
`unpatentability of these claims be rendered.
`
`II. MANDATORY NOTICES
`A. Real Parties-in-Interest
`The real party-in-interest for this Petition is I.M.L. SLU.
`
`B. Related Matters
`The ’839 Patent is asserted in nine pending federal district court actions,
`
`listed below. Petitioner is a defendant in the first listed action.
`
`(1) WAG Acquisition, LLC v. Sobonito Investments, Ltd. et al., Case No.
`
`2:14-cv-1661-ES-JAD (D.N.J.); (2) WAG Acquisition, LLC v. Multi Media, LLC et
`
`al., Case No. 2:14-cv-2340-ES-JAD (D.N.J.); (3) WAG Acquisition, LLC v. Data
`
`Conversions, Inc. et al., Case No. 2:14-cv-2345-ES-JAD (D.N.J.); (4) WAG
`
`Acquisition, LLC v. Flying Crocodile, Inc. et al., Case No. 2:14-cv-2674-ES-MAH
`
`(D.N.J.); (5) WAG Acquisition, LLC v. Gattyàn Group S.à r.l. et al., Case No. 2:14-
`
`cv- 2832-ES-JAD (D.N.J.); (6) WAG Acquisition, LLC v. FriendFinder Networks
`
`Inc. et al., Case No. 2:14-cv-3456-ES-JAD (D.N.J.); (7) WAG Acquisition, LLC v.
`
`
`
`1
`
`

`
`
`
`Vubeology, Inc. et al., Case No. 2:14-cv-4531-ES-JAD (D.N.J.); (8) WAG
`
`Acquisition, LLC v. Gamelink International Limited et al. Case No. 2:15-cv-3416
`
`(D.N.J.); and (9) WAG Acquisition LLC v. WebPower, Inc. et al., Case No. 2:15-
`
`cv-03581 (D.N.J). One other related litigation, WAG Acquisition, LLC v. MFCXY,
`
`Inc. et al., Case No. 2:14-cv-3196-ES-MAH (D.N.J.), has been dismissed.
`
`The following chart identifies other IPR proceedings for the ’839 Patent, as
`
`well as for related patents: U.S. Patent No. 8,122,141 (the “’141 patent”), U.S.
`
`Patent No. 8,185,611 (the “’611 Patent”), and U.S. Patent No. 8,327,011 (the “’011
`
`Patent”). The ‘839 Patent is a continuation of the ‘611 Patent.
`
`Patent Number
`
`Current Status
`
`Petition Number
`
`(Petition Date)
`
`8,122,141
`
`Claims 1-28 challenged, petition denied.
`
`IPR2015-01037
`
`(Apr. 14, 2015)
`
`8,122,141
`
`Claims 1-28 challenged, petition pending.
`
`IPR2016-01238
`
`(June 21, 2016)
`
`
`
`2
`
`

`
`
`
`
`
`Patent Number
`
`Current Status
`
`Petition Number
`
`(Petition Date)
`
`8,185,611
`
`Claims 1-18 challenged, petition denied.
`
`IPR2015-01035
`
`(Apr. 14, 2015)
`
`8,185,611
`
`Claims 1-18 challenged, petition pending.
`
`IPR2016-01162
`
`(June 6, 2016)
`
`8,327,011
`
`Claims 1-4 challenged, petition denied.
`
`IPR2015-01033
`
`(Apr. 14, 2015)
`
`8,327,011
`
`Claims 1-4 challenged, petition pending
`
`IPR2016-01161
`
`(June 6, 2016)
`
`3
`
`

`
`
`
`Patent Number
`
`Current Status
`
`Petition Number
`
`(Petition Date)
`
`8,364,839
`
`Claims 1-21 challenged, trial instituted for claims 1, 3,
`
`IPR2015-01036
`
`(Apr. 14, 2015)
`
`4, 6-8, 10, 11, 13-15, 17, 18, 20 and 21, petition
`
`denied for claims 2, 5, 9, 12, 16 and 19.
`
`8,364,839
`
`Claims 1-21 challenged, petition pending.
`
`IPR2016-01239
`
`(June 21, 2016)
`
`C. Counsel and Service Information
`Counsel:
`David R. Yohannan (Reg. No. 37,480) (Lead)
`
`Beth D. Jacob (Backup) (pro hac to be filed)
`
`Address:
`
`Kelley Drye & Warren LLP
`
`3050 K Street, N.W.
`
`Washington, D.C. 20007
`
`Phone and Fax:
`
`P: (202) 342-8400, F: (202) 342-8451
`
`Please send all correspondence to the lead counsel at the address shown
`
`above. Petitioner consents to service by email at: dyohannan@kelleydrye.com and
`
`
`
`4
`
`

`
`
`
`DCpatentdocket@kelleydrye.com. A Power of Attorney is filed concurrently
`
`herewith under 37 C.F.R. § 42.10(b). The Office is authorized to charge the fees
`
`set forth in 37 C.F.R. § 42.15(a) to Deposit Account No. 03-2469, as well as any
`
`additional fees that might be due in connection with this Petition.
`
`III. CERTIFICATION OF GROUNDS FOR STANDING
`Petitioner hereby certifies that the patent for which review is sought is
`
`available for Inter Partes Review and that Petitioner is not barred or estopped
`
`from requesting an Inter Partes Review challenging the patent claims on the
`
`Grounds identified in the Petition. In the co-pending litigation, Petitioner’s waiver
`
`of service was filed August 24, 2015. Ex. 1012. “[I]n the situation where the
`
`petitioner waives service of a summons, the one year time period [under 35 U.S.C.
`
`315(b)] begins on the date on which such a waiver is filed.” Motorola Mobility
`
`LLC v. Arnouse, IPR2013-00010, Paper 20 at 6 (PTAB Jan. 30, 2013) (informative
`
`decision); see also Brinkmann Corporation v. A&J Manufacturing, LLC, Case No.
`
`IPR2015-00056, Paper 10 at 6-7 (PTAB, Mar. 23, 2015) (citing additional cases).
`
`IV. STATEMENT OF PRECISE RELIEF REQUESTED
`Petitioner respectfully requests that Claims 1-21 of the ’839 Patent (Ex.
`
`1001) be canceled based on the following Grounds of Unpatentability, set forth and
`
`explained in detail in the following sections:
`
`
`
`5
`
`

`
`
`
`Ground 1: Claims 1-2, 4, 6-9, 11, 13-16, 18 and 20-21 are unpatentable under 35
`
`U.S.C. § 103(a) as obvious over Chen (Ex. 1002) in view of Chen File History (Ex.
`
`1003).
`
`Ground 2: Claims 3, 10 and 17 are unpatentable under 35 U.S.C. § 103(a) as
`
`obvious over Chen (Ex. 1002) in view of Chen File History (Ex. 1003) and ISO-
`
`11172 (Ex. 1009, 1010, 1011).
`
`Ground 3: Claims 5, 12 and 19 are unpatentable under 35 U.S.C. § 103(a) as
`
`obvious over Chen (Ex. 1002) in view of Chen File History (Ex. 1003) and
`
`Willebeek (Ex. 1004).
`
`Ground 4: Claims 5, 12 and 19 are unpatentable under 35 U.S.C. § 103(a) as
`
`obvious over Chen (Ex. 1002) in view of Chen File History (Ex. 1003) and Carmel
`
`(Ex. 1005).
`
`V. THRESHOLD REQUIREMENT FOR INTER PARTES REVIEW
`A. Reasonable Likelihood of Invalidity
`A petition for Inter Partes Review must demonstrate “a reasonable
`
`likelihood that the petitioner would prevail with respect to at least 1 of the claims
`
`challenged in the petition.” 35 U.S.C. § 314(a). This Petition meets this threshold.
`
`All of the elements of claims 1-21 of the ’839 Patent are rendered invalid by the
`
`prior art as explained below in the proposed Grounds of Unpatentability. Specific
`
`
`
`6
`
`

`
`
`
`motivation or suggestion to combine the references is provided herein and in the
`
`accompanying Declaration of Dr. Gareth Loy (Ex. 1006).
`
`B. Review Is Appropriate In View Of Prior IPRs
`The primary reference relied upon in this petition, Chen, was included in a
`
`prior IPR petition for the ‘839 Patent, IPR 2016-01239, which was filed by another
`
`party and which is pending, and in a prior IPR filed by another party which was
`
`instituted, IPR 2015-01036. For the reasons below, however, Petitioner
`
`respectfully submits that the Board should not deny this petition as duplicative
`
`under 35 U.S.C. § 325(d).
`
`First, with respect to the instituted IPR and Grounds 3-4, Chen is combined
`
`with different references as compared with the other two IPRs to render claims 5,
`
`12 and 19 obvious. An IPR has not been instituted for these claims.
`
`Second, the PTAB has acknowledged that, in determining whether to
`
`exercise its discretion under 325(d), “we take into account the identity of the
`
`parties—in particular, whether the second petition is filed by the same party as the
`
`first.” Ube Maxell Co., Ltd. v. Celgard LLC, Case IPR2015-01511, Paper 10 at 12
`
`(PTAB Jan. 7, 2016). Here, Petitioner is not the same party, and is not a party-in-
`
`interest to the previously filed action. Id. at 13 (citing Square, Inc. v. Protegrity
`
`Corp., Case CBM2014-00182, Paper 16 at 8 (PTAB Mar. 5, 2015).
`
`
`
`7
`
`

`
`
`
`Third, the PTAB has acknowledged that “we have taken into account the
`
`potential prejudice to the petitioner if the second petition is denied institution.”
`
`Here, the potential prejudice is great: Petitioner’s statutory bar date under 35
`
`U.S.C. § 315(b) is August 24, 2016. If the parties to the still-pending IPR settle,
`
`and the IPR is dismissed, Petitioner will be barred from re-filing its petition. The
`
`present petition is Petitioner’s only option for relief at the PTAB.
`
`VI. OVERVIEW OF THE ’839 PATENT AND ADMITTED PRIOR ART
`The ’839 Patent issued from U.S. Patent Application No. 13/385,375, filed
`
`on February 16, 2012. The ’839 Patent claims priority, through a series of
`
`continuation and continuation-in-part applications, on Provisional Application No.
`
`60/231,997, filed on September 12, 2000. For purposes of comparison with prior
`
`art, the earliest possible priority date of the claims of the ’839 Patent is September
`
`12, 2000.
`
`The ’839 Patent is directed to methods and systems for sending streaming
`
`media, such as audio or video files composed of a plurality of time-sequenced data
`
`elements from a server to a user computer via the Internet. Ex. 1001, ’839 Patent,
`
`3:24-27; 6:7-12. With reference to Fig. 1, reproduced below, the ‘839 Patent
`
`system may include a server 12 connected to the Internet 10 for transmitting the
`
`streaming media data elements from a server FIFO buffer 14 to a user buffer 20 of
`
`a user computer 18.
`
`
`
`8
`
`

`
`
`
`
`
`In order to obtain streaming media, it was known prior to the ‘839 Patent for
`
`a user to employ a media player software application to hear or view an audio
`
`and/or video data stream. See id., 2:39-44. Internet bandwidth limitations,
`
`however, required pre-buffering of the initial data elements of the streamed media
`
`prior to the start of playback. According to the ‘839 Patent, buffering of 10-20
`
`seconds of streaming media was required at the media player before playback
`
`began in prior art systems. See id., 2:35-37. If there were gaps in the receipt of
`
`audio/video data after playback was started, due to Internet slowness, the buffer
`
`
`
`9
`
`

`
`
`
`associated with the media player would deplete. See id., 2:53-54. With regard to
`
`buffering, and its limitations, it was believed by the ‘839 Patent inventor, that:
`
`Because transmission of audio/video media data to the
`user takes place at the rate it is played out, the user's
`buffer level can never be increased or replenished while
`it is playing. Thus, gaps in the receipt of audio/video
`media data inexorably cause the buffer level to
`decrease from its initial level. In time, extended or
`repeated occurrences of these gaps empty the user's
`buffer. The audio/video material stops playing, and the
`buffer must be refilled to its original predetermined
`level before playing of the media resumes.
`Id., 2:54-63.
`
`The ‘839 Patent purports to provide a solution to the problem presented by
`
`such gaps and associated “dropouts,” i.e., interruptions in the continuous listening
`
`or viewing of audio and video streams. The ’839 Patent correctly acknowledges
`
`that it was known in the prior art to use a pre-buffering technique to store up
`
`enough audio or video data in the user’s computer so that it can play the audio or
`
`video with a minimum of dropouts. See id., 2:24-27.
`
`However, the presumed prior art deficiency concerning available pre-
`
`buffering techniques that the ‘839 Patent invention purports to remedy had already
`
`been solved. See Ex. 1006, Loy Decl., ¶¶ 45-47 . Specifically, the ‘839 Patent
`
`incorrectly asserts that a problem existed because it was only known (at the time)
`
`
`
`10
`
`

`
`
`
`to transmit audio and video data at the rate it was to be played back on the
`
`associated media player (see Ex. 1001, ‘839 Patent, 2:45-52) and therefor there
`
`was (1) need for a 10-20 second delay at the outset of playback to fill the media
`
`player buffer, and (2) no way to refill the buffer without interruption once it was
`
`completely depleted. See id., 2:53-3:19. Indeed, the ‘839 Patent expressly (and
`
`incorrectly) states that its invention “is distinctly different from prior art, in which
`
`media data is only sent from the server 12 to the user computer 18 at the rate at
`
`which it is to be played out.” Id., 8:36-39 (emphasis added); Ex. 1006, Loy Decl.,
`
`¶ 46. This “transmit rate – limited to playback rate” foundation on which the ‘839
`
`Patent invention is built turns out to have been nonexistent when viewed in light of
`
`the Chen prior art, discussed infra. Based on the foregoing faulty premise, the
`
`’839 Patent asserts that it represents an advance because it transmits data from the
`
`server “more rapidly than it is played out by the user system under conditions
`
`wherein the user’s computer buffer is not full,” at “a rate faster than the playback
`
`rate.” Ex. 1001, ‘839 Patent, 15:17-31.
`
`The ‘839 Patent is also directed to providing “a system for distributing via
`
`the Internet streaming media composed of a plurality of time-sequenced data
`
`elements.” Id., 6:7-9. These sequential data elements are identified by serial
`
`numbers which permit the user’s computer to keep track of, and request, specific
`
`data elements that are required for playback. See id., 14:7-24.
`
`
`
`11
`
`

`
`
`
`While the ‘839 Patent discloses and claims the use of sequentially numbered
`
`data elements, it does not purport to have invented them. The user computer
`
`transmits a request specifying the serial numbers of requested data elements “[v]ia
`
`the use of standard data communications protocol techniques such as TCP.” Id.,
`
`14:14-17.
`
`VII. OVERVIEW OF THE NEWLY APPLIED PRIOR ART
`A. Chen
`Chen (Ex. 1002) issued on October 13, 1998, and is prior art under at least
`
`35 U.S.C. § 102(b). It was not cited during original prosecution.
`
`Prior to the ‘839 Patent, Chen disclosed the same type of system:
`
`A method in computer networks in which a client
`machine (playback client computer) requests
`multimedia files, such as compressed video clips, from
`a server (storage server computer). The transmission
`uses digital data packets. In the case of video files, the
`packet headers identify the video frame and the
`sequence number of each packet derived from the
`frame.
`
`Ex. 1002, Chen, Abstract.
`
`
`
`12
`
`

`
`
`
`With reference to Fig. 1 of Chen, a client machine (e.g., computer) 20 is
`
`connected to a server 21 via data connections 5 and 6 over a computer network so
`
`that multimedia files may be retrieved at the client machine from the server. See
`
`id., 4:65-5:5. The client machine 20 has three interacting processes: the client
`
`agent 30 which interfaces with the network interface 3 and the multimedia
`
`application 4 in the client machine. Id., 5:5-8. The client agent 30 has the primary
`
`responsibility of retrieving from the server control 1 the right set of multimedia
`
`data at the right time to satisfy the needs of the multimedia application 4. Id., 5:17-
`
`20. The client agent 30 maintains a packet buffer 31 (a structure for temporary
`
`data storage) as a cache storage (temporary data storage center). Id., 5:20-22.
`
`The server 21 has three component processes: the server control 1 which
`
`interfaces with the storage subsystem 12 and with the network interface 2. Id.,
`
`5:27-29. Similar to the packet buffer 31 in the client agent 30, a stream buffer 11
`
`in the server control 1 holds the data that has been read from the storage subsystem
`
`12. Id., 5:30-32. Interactions between the server control 1 and the client agent 30
`
`
`
`13
`
`

`
`
`
`go through the network connecting the two machines. Id., 5:34-36. The control
`
`channel 5 serves to exchange control messages and the data channel 6 serves to
`
`transmit multimedia data from the server 1 to the client agent 30. Id., 5:39-42.
`
`
`
`The client agent 30 is described in detail in connection with Fig. 2 of Chen.
`
`Fig. 2 illustrates the connection of the client agent 30 to the network where two
`
`execution paths exist, one for data and one for control messages. Id., 5:45-49. The
`
`data execution path starts from the data receiver 32, which receives incoming data
`
`packets from the network. Id., 5:49-51. Interaction between the various
`
`components of the client agent 30 (i.e., between the data receiver 32, the packet
`
`buffer 33, the output processor 34, the application interface 35, the client controller
`
`
`
`14
`
`

`
`
`
`36, the command processor 37, and the buffer manager 38) results in the output
`
`processor 34 delivering data to the multimedia application 4. See id., 5:51-57.
`
`The packet buffer 33 stores data packets until the multimedia application 4
`
`requests that they be delivered to it. Id., 5:57-59. If the packet buffer 33 does not
`
`have the requested data available, the client controller 36 signals the command
`
`processor 37 to send a command packet request to the server control (1 in Fig. 1)
`
`for immediate retrieval of the requested data. Id., 5:59-64.
`
`The buffer manager 38 manages the structure of the data in the packet buffer
`
`33. Id., 6:1-2. Ideally the packet buffer 33 should have enough data: (i) to
`
`minimize the possibility of not having the requested data, and (ii) still have enough
`
`free buffer space (memory space) to receive new data packets. Id., 6:4-7. "Water
`
`Marks" in the packet buffer 33 on the client side regulate the server's (21 of Fig. 1)
`
`transmission rate. See id., 6:7-15. Three transmission modes are defined:
`
`NORMAL, RUSH, and PAUSE. Id. Based on the amount of data in the packet
`
`buffer 33 the client agent 30 decides which is the appropriate mode. Id. The client
`
`agent 30 changes the transmission mode based on a series of rules, explained using
`
`a “water mark” and bucket of water analogy. See id., 6:14-19.
`
`In the model, the client agent 30 packet buffer 31 is analogous to a water
`
`bucket and the multimedia data packets in the packet buffer are analogous to water
`
`that flows into and out of the bucket. See id., 6:17-19. Water flows into the bucket
`
`
`
`15
`
`

`
`
`
`intermittently and exits the bucket through a spout analogous to multimedia data
`
`entering the packet buffer intermittently and exiting the packet buffer to provide
`
`audio and/or video data to a media player for enjoyment by a user. See id.
`
`The bucket has high and lower "water marks". In the
`just-in-time retrieval method, when the amount of data
`falls between the water marks, transmission occurs in
`NORMAL mode. . . .Transmission enters PAUSE
`mode when the amount of data exceeds the high water
`mark, i.e., there is too much data in the client agent
`packet buffer (33). Transmission occurs in RUSH mode
`when the amount of data falls below the lower water
`mark, i.e., there is not enough data in the client agent
`packet buffer (33). The client agent (30) sends a
`"NORMAL-TO-RUSH" command if the amount of
`data decreases below the low water mark. The client
`agent (30) sends a "NORMAL-TO-PAUSE" command
`if the amount of data increases above the high water
`mark. The client agent sends a "PAUSE-TO-
`NORMAL" command if the amount of data decreases
`from above to below the high water mark. The client
`agent (30) sends a "RUSH-TO-NORMAL" command if
`the amount of data increases from below the lower
`water mark to above the low water mark.
`
`Id., 6:28-54.
`
`
`
`16
`
`

`
`
`
`Fig. 3, reproduced below, illustrates the structure of the packet buffer 33,
`
`which includes one or more data packets (each having a packet header 52 and
`
`multimedia data 60) organized into one or more video frames. See id., 6:55-57.
`
`
`
`The client agent 30 has a packet buffer 31 that normally holds 1-5 video frames.
`
`Id., Abstract. The transmission rate is adjusted to keep that buffer filled within its
`
`normal range. Id. In a preferred embodiment, the transmission rate of the data
`
`packet stream is based on the frame rate of the file. Id., 3:59-63. If the data in the
`
`buffer 31 of the client agent 30 is below a selected standard ("water mark"), the
`
`transmission rate is increased; if above a selected standard it is decreased. Id.,
`
`4:41-44.
`
`
`
`17
`
`

`
`
`
`The Chen invention would have been implemented by a POSITA to initially
`
`transmit data packets in RUSH mode. Ex. 1006, Loy Decl., ¶¶ 53, 107. The
`
`transmission mode is set to “Mode=RUSH” when “a low amount of data exists in
`
`the client agent’s packet buffer (33).” Ex. 1002, Chen, 10:14-15. Initially, when
`
`playback is first selected so as to trigger initial transmission of a data file, the Chen
`
`packet buffer has a low amount (i.e., zero) of data. Ex. 1006, Loy Decl., ¶ 53.
`
`Initial transmission in RUSH mode is further indicated by Claims 4 and 5 of Chen
`
`which specify (a) selecting 1-5 video frames to be stored within the client agent
`
`packet buffer, and (b) increasing the transmission rate (i.e., transitioning from
`
`NORMAL to RUSH mode) if the number of frames in the buffer is below the
`
`selected range. See Ex. 1002, Chen, 11:8-16. In RUSH mode, data is transmitted
`
`as fast as possible. Id., 12:26-27; 13:62-64 (claims 18, 29). Since Chen starts with
`
`no data in the client agent buffer, a POSITA would have started the Chen system in
`
`RUSH mode. Ex. 1006, Loy Decl., ¶¶ 53, 107.
`
`Chen also discloses information that informs a POSITA that “RUSH mode,”
`
`whether occurring initially or later, is at a transmission rate more rapid than
`
`playback rate. Id., ¶¶ 52-55, 107-108. When the amount of data in the packet
`
`buffer (water in the bucket) crosses from below the lower water mark to above it,
`
`transmission switches from RUSH mode to NORMAL mode. Ex. 1002, Chen,
`
`6:52-54. In NORMAL mode, frame level pacing is provided (id., 10:3-4) – i.e.,
`
`
`
`18
`
`

`
`
`
`transmission at the playback rate. Ex. 1006, Loy Decl., ¶¶ 55, 107. If the amount
`
`of data falls below the low water mark, transmission changes back to RUSH mode.
`
`Ex. 1002, Chen, 6:42-47.
`
`Chen discloses assigning packet sequence numbers (serial identifiers) to the
`
`data packets, which is the “packet sequence number of the last received packet”
`
`making up the streaming media. See id., 6:55-7:2; 7:24-32. The client agent 30
`
`uses packet sequence numbers to maintain a list of lost packets. See id., 7:33-35.
`
`With regard to lost packets, Chen states that:
`
`To detect lost packets. . . .the client agent (30) uses a
`register to maintain a variable Last Pkt. Seq. No. (51),
`which is the packet sequence number of the last
`received packet. If the Pkt. Seq. No. of the newly
`arriving packet denoted as New Pkt Seq No differs
`from (Last Pkt. Seq. No. +1), then a packet loss has
`occurred. Specifically, the packets with Pkt. Seq. No.'s
`from (Last Pkt. Seq. No. +1) to (New Pkt. Seq. No. -1)
`have been lost.
`Id., 7:25-32. The client agent 30 may send a “retransmission request” for lost
`
`packets to the server control 1. See id., 7:35-39. A “retransmission request” may
`
`be sent repeatedly for lost packets. See id., 7:41-43. Thus, the packet sequence
`
`number list maintained by the client agent serves as a “pointer” into the server
`
`
`
`19
`
`

`
`
`
`stream buffer 11 from which replacement packets may be sent. Ex. 1006, Loy
`
`Decl., ¶ 112.
`
`B. Chen File History
`Chen File History (Ex. 1003) has previously been determined by the Board
`
`to constitute prior art relative to a Price patent credited with a priority date of
`
`September 12, 2000 and thus is prior art as to the ‘839 Patent. See IPR2015-01035,
`
`Paper 8, 18.
`
`Chen File History includes a declaration by the inventor of Chen and
`
`documentation of the commercial embodiment of claimed system in Chen.
`
`Notably, Chen File History discloses the use of RUSH mode when first opening a
`
`file. See Ex. 1003, Chen File History, ChenFH086. Use of RUSH mode results in
`
`the Chen client agent or media player receiving media data elements at a rate more
`
`rapid than the rate at which the media data elements are to be played out. Ex.
`
`1006, Loy Decl., ¶¶ 92-94. Specifically, Chen discloses use of a QVS Client
`
`Server Protocol that “Read data from disk and rush them to [Client Agent]”
`
`initially. Ex. 1003, Chen File History, ChenFH086 In Chen File History, when
`
`NORMAL mode is used, the server control “transmit[s] data according to time and
`
`player's playout rate,” i.e., at a playback rate. Id.; Ex. 1006, Loy Decl., ¶ 92.
`
`
`
`20
`
`

`
`
`
`C. Willebeek
`Willebeek (Ex. 1004), was published in the IBM Journal of Research and
`
`Development, Volume 42 No. 2 in March 1998 and qualifies as prior art under at
`
`least 35 U.S.C. § 102(b). Ex. 1004, Willebeek, 269. Willebeek was not cited
`
`during original prosecution.
`
`Willebeek discloses a method of displaying streamed digital video data,
`
`including live video, on a client computer using buffers at the client and server.
`
`See id., 269, 277-78, Fig. 6. According to Willebeek, by 1998 it was known that
`
`“[a]udio and video streaming enables clients to select and receive audio and video
`
`content from servers across the network and to begin hearing and seeing the
`
`content as soon as the first few bytes of the stream arrive at the client. Id., 269
`
`(emphasis added). “If the network conditions are suitable (sufficient sustained
`
`bandwidth is available), this file, streaming across the network, is played at the
`
`client immediately.” Id., 270. Willebeek also discloses that playback can begin
`
`“immediately” if the playback rate (i.e., that provided by NORMAL mode in
`
`Chen) is less than the initial data transmission rate from the server to the client
`
`(i.e., RUSH mode in Chen). See id., 273. The upshot of the foregoing is that
`
`Willebeek teaches that if the Chen system initially transmits data elements in
`
`RUSH mode, which it did, playback could begin immediately after the receipt of
`
`the first few bytes of data. Ex. 1006, Loy Decl., ¶¶ 76-81. Further, since a
`
`
`
`21
`
`

`
`
`
`POSITA would have known at the time that a frame of video typically contains
`
`many more than a “few bytes” of data, a POSITA would have interpreted
`
`Willebeek to teach the initiation of video playback of streamed media no later than
`
`the time that a full frame of video data arrived at the client, which in Chen is while
`
`the client buffer is still filling. Id., ¶ 81.
`
`Willebeek also confirms that POSITAs would have been aware at the time
`
`that “[s]treaming media requires that data be transmitted from a server to a client at
`
`a sustained bit rate that is high enough to maintain continuous and smooth
`
`playback at the receiving client station.” Ex. 1004, Willebeek, 269. (emphasis
`
`added). Even at lower bit rates, “continuous playback” was the goal of Willibeek.
`
`Id., 270. The overarching goal of Willebeek, even when connections were slow,
`
`was for “the file [to be] played once uninterrupted playback can be ensured.” Id.
`
`In other words, it was known that to stream media, continuous or uninterrupted
`
`playback was required. Ex. 1006, Loy Decl., ¶¶ 79-80.
`
`Willebeek also teaches that it is appropriate in some circumstances to trade
`
`frame rate for frame quality (bits per frame) while maintaining a constant average
`
`bit rate to provide smoother motion or sharper images, as appropriate, depending
`
`on the content and scene changes in the video. Ex. 1004, Willebeek, 273. This
`
`feature of Willebeek indicates it could be used to modify and trade the constant
`
`
`
`22
`
`

`
`
`
`frame rate of Chen for increased frame quality and a constant average bit rate, so
`
`as to provide sharper images. Ex. 1006, Loy Decl., ¶ 82.
`
`With regard to filling a server buffer, Willebeek discloses a system which is
`
`capable of filling a server buffer at a playback rate. Willebeek streams a