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,185,611
`
`Issue Date: May 22, 2012
`
`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,185,611 to Price (the “’611 Patent”)
`
`1002
`
`1003
`
`1004
`
`1005
`
`1006
`
`1007
`
`1008
`
`1009
`
`1010
`
`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,405,256 to Lin et al. (“Lin”)
`
`Declaration of Dr. Gareth Loy in Support of Inter Partes
`Review of U.S. Patent 8,185,611
`Curriculum Vitae of Dr. Gareth Loy
`
`Prosecution history for U.S. Patent No. 8,185,611
`
`Zheng & Atiquzzaman, Multimedia Over High Speed
`Networks: Reducing Network Requirements With Fast Buffer
`Fillup, Global Telecommunications Conference (IEEE 1998)
`(“Zheng”)
`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
`V.
`REVIEW .......................................................................................................... 6
`A.
`Reasonable Likelihood of Invalidity ..................................................... 6
`B.
`Review Is Appropriate In View Of Prior IPRs ..................................... 7
`VI. OVERVIEW OF THE ’611 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.
`Zheng ................................................................................................... 24
`E.
`Lin ........................................................................................................ 26
`VIII. CLAIM CONSTRUCTION .......................................................................... 26
`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-18 Are Obvious Over Chen In View Of
`Chen File History and Willebeek ........................................................ 29
`1.
`Claims 1, 8, and 14 .................................................................... 29
`2.
`Claims 3, 9, and 15.................................................................... 54
`
`
`
`ii
`
`

`
`
`
`3.
`
`4.
`
`5.
`
`Claims 4 and 16 ....................................................................... ..55
`
`Claims 5 and 12 ....................................................................... ..58
`
`Claim 2 .................................................................................... ..61
`
`B.
`
`Ground 2: Claims 1-18 Are Obvious Over Chen In View Of
`
`C.
`
`Ground 3: Claims 1-18 Are Obvious Over Chen In View Of
`
`3.
`Claims 4 and 16 ......................................................................... 55
`4.
`Claims 5 and 12 ......................................................................... 58
`5.
`Claim 2 ...................................................................................... 61
`6.
`Claims 6, 10, 13 and 17 ............................................................ 61
`Claims 6, 10, 13 and 17 .......................................................... ..61
`6.
`7.
`Claims 7, 11, 18 ........................................................................ 61
`Claims 7, 11, 18 ...................................................................... ..61
`7.
`B. Ground 2: Claims 1-18 Are Obvious Over Chen In View Of
`Chen File History, Willebeek and Lin ................................................ 61
`Chen File History, Willebeek and Lin .............................................. ..61
`C. Ground 3: Claims 1-18 Are Obvious Over Chen In View Of
`Chen File History, Willebeek And Zheng........................................... 63
`Chen File History, Willebeek And Zheng ......................................... ..63
`XI. CONCLUSION AND STATEMENT OF PRECISE RELIEF
`REQUESTED ................................................................................................ 65
`REQUESTED .............................................................................................. ..65
`CERTIFICATE OF COMPLIANCE ....................................................................... 66
`CERTIFICATE OF SERVICE ................................................................................ 67
`
`XI.
`
`CONCLUSION AND STATEMENT OF PRECISE RELIEF
`
`CERTIFICATE OF COMPLIANCE ..................................................................... ..66
`
`CERTIFICATE OF SERVICE .............................................................................. ..67
`
`iii
`
`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-18 of U.S. Patent No.
`
`8,185,611 (Ex. 1001), assigned to WAG Acquisition, LLC (“Patent Owner”).
`
`Petitioner challenges the patentability of claims 1-18 of the ‘611 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 ’611 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
`
`
`
`1
`
`

`
`
`Inc. et al., Case No. 2:14-cv-3456-ES-JAD (D.N.J.); (7) WAG Acquisition, LLC v.
`
`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 ’611 Patent, as
`
`well as for related patents: U.S. Patent No. 8,122,141 (the “’141 patent”), U.S.
`
`Patent No. 8,327,011 (the “’011 Patent”), and U.S. Patent No. 8,364,839 (the “’839
`
`Patent”). The ‘611 Patent is a parent of the ‘839 Patent. The ‘141 Patent and the
`
`‘611 Patent are sister applications which are both continuations of U.S. Patent No.
`
`7,716,358.
`
`Patent Number
`
`Current Status
`
`Petition Number
`
`(Petition Date)
`
`8,122,141
`
`Claims 1-28 challenged, petition denied.
`
`IPR2015-01037
`
`(Apr. 14, 2015)
`
`
`
`2
`
`

`
`
`
`
`
`Patent Number
`
`Current Status
`
`Petition Number
`
`(Petition Date)
`
`8,122,141
`
`Claims 1-28 challenged, petition pending.
`
`IPR2016-01238
`
`(June 21, 2016)
`
`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
`
`IPR2015-01036
`
`(Apr. 14, 2015)
`
`Claims 1-21 challenged, trial instituted for claims 1,
`3, 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
`
`DCpatentdocket@kelleydrye.com. A Power of Attorney is filed concurrently
`
`
`
`4
`
`

`
`
`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. 1010. “[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-18 of the ’611 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-18 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 2: Claims 1-18 are unpatentable under 35 U.S.C. § 103(a) as obvious
`
`over Chen (Ex. 1002) in view of Chen File History (Ex. 1003), Willebeek (Ex.
`
`1004) and Lin (Ex. 1006).
`
`Ground 3: Claims 1-18 are unpatentable under 35 U.S.C. § 103(a) as obvious
`
`over Chen (Ex. 1002) in view of Chen File History (Ex. 1003), Willebeek (Ex.
`
`1004) and Zheng (Ex. 1009).
`
`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-18 of the ’611 Patent are rendered invalid by the
`
`prior art as explained below in the proposed Grounds of Unpatentability. Specific
`
`motivation or suggestion to combine the references is provided herein and in the
`
`accompanying Declaration of Dr. Gareth Loy (Ex. 1006).
`
`
`
`6
`
`

`
`
`
`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 ‘611 Patent, IPR 2016-01162, which was filed by another
`
`party and which is pending. 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 all Grounds, Petitioner here relies upon the
`
`combination of Chen with different prior art then used in the prior pending IPR.
`
`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).
`
`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,
`
`
`
`7
`
`

`
`
`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 ’611 PATENT AND ADMITTED PRIOR ART
`The ’611 Patent issued from U.S. Patent Application No. 12/800,177, filed
`
`on May 10, 2010. The ’611 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. The earliest possible priority date of the claims of the
`
`’611 Patent is September 12, 2000.
`
`The ’611 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, ’611 Patent,
`
`3:23-25; 6:7-12. With reference to Fig. 1, reproduced below, the ‘611 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 ‘611 Patent for
`
`a user to employ a media player software application to hear or view an audio
`
`and/or video data stream via the Internet. See id., 2:12-13; 2:35-40. 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 ‘611 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:31-33. If there were gaps in
`
`
`
`9
`
`

`
`
`the receipt of audio/video data after playback was started, due to Internet slowness,
`
`the buffer associated with the media player would deplete. See id., 2:49-50.
`
`The ‘611 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 ’611 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:20-23.
`
`However, the presumed prior art deficiency concerning available pre-
`
`buffering techniques that the ‘611 Patent invention purports to remedy had already
`
`been solved. Ex. 1006, Loy Decl., ¶¶ 45-47. Specifically, the ‘611 Patent
`
`incorrectly asserts that a problem existed because it was only known (at the time)
`
`to transmit audio and video data at the rate it was to be played back on the
`
`associated media player (see Ex. 1001, ‘611 Patent, 2:41-48) 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:49-3:17; Ex. 1006, Loy Decl., ¶ 46. Indeed, the
`
`‘611 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.” Ex. 1001, ‘611
`
`
`
`10
`
`

`
`
`Patent, 8:36-39 (emphasis added). Based on a faulty premise, the ’611 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.” Id., 15:17-29;
`
`see also Ex. 1006, Loy Decl., ¶ 46.
`
`The ‘611 Patent is also directed to providing “streaming media composed of
`
`a plurality of time-sequenced data elements.” Ex. 1001, ‘611 Patent, 6:7-9
`
`(emphasis added). 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:5-22.
`
`While the ‘611 Patent discloses and claims the use of sequentially numbered
`
`data elements, it does not purport to have invented them. As noted in the above
`
`extract from the ‘611 Patent, 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., 8:9-13; 14:12-15. Thus,
`
`the ‘611 Patent concedes that the delivery of data in the proper sequence is in the
`
`prior art.
`
`
`
`11
`
`

`
`
`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 ‘611 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.
`
`With reference to Fig. 1 of Chen (above), a client machine (e.g., computer)
`
`20 is connected to a server 21 via data connections 5 and 6 over a computer
`
`
`
`
`
`12
`
`

`
`
`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.
`
`
`
`13
`
`

`
`
`
`
`
`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
`
`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.
`
`
`
`14
`
`

`
`
`
`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 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 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
`
`intermittently and exits the bucket through a spout analogous to multimedia data
`
`
`
`15
`
`

`
`
`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
`
`
`
`17
`
`

`
`
`transmission rate is increased; if above a selected standard it is decreased. Id.,
`
`4:41-44.
`
`The Chen invention would have been implemented by a POSITA to initially
`
`transmit data packets in RUSH mode. Ex. 1006, Loy Decl., ¶¶ 53, 117. 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,
`
`117. 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, 117.
`
`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, 117-118. When the amount of data in the packet
`
`buffer (water in the bucket) crosses from below the lower water mark to above it,
`
`
`
`18
`
`

`
`
`transmission switches from RUSH mode to NORMAL mode. Id., 6:52-54. In
`
`NORMAL mode, frame level pacing is provided (id., 10:3-4) – i.e., transmission at
`
`the playback rate. Ex. 1006, Loy Decl., ¶¶ 55, 118. 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 may send a “retransmission request” for lost packets
`
`to the server control. See id., 7:35-39. A “retransmission request” may be sent
`
`
`
`19
`
`

`
`
`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 stream
`
`buffer from which replacement packets may be sent.
`
`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 ‘611 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., ¶¶ 80-82. Specifically, Chen discloses use of a QVS Client
`
`Server Protocol that “Read data from disk and rush them to [Client Agent]”. 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. Ex. 1003,
`
`Chen File History, ChenFH086; Ex. 1006, Loy Decl., ¶ 82.
`
`
`
`
`
`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; Ex. 1006, Loy Decl., ¶ 62.
`
`Willebeek was not cited during original prosecution, but is cited in prior filed
`
`IPR2016-01238 concerning the ‘141 Patent.
`
`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 Ex. 1004, Willebeek, 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
`
`
`
`21
`
`

`
`
`the first few bytes of data. Ex. 1006, Loy Decl., ¶¶ 64-69, 130-131. Further, since
`
`a 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. See id., ¶ 69.
`
`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., ¶¶ 67-68, 128-129.
`
`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., ¶ 70.
`
`With regard to constant bit rate, Willebeek discloses a system which is
`
`capable of filling a server buffer at a constant fill rate which is at a playback rate.
`
`Ex. 1006, Loy Decl., ¶¶ 75-79, 132-138. Willebeek streams audio and video
`
`generated by a live source. Ex. 1004, Willebeek, 277. When doing so, “audio and
`
`video inputs are converted