`
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`________________
`
`FRIENDFINDER NETWORKS INC., STREAMRAY INC., WMM, LLC,
`WMM HOLDINGS, LLC, AND MULTI MEDIA, LLC
`
`Petitioners
`
`v.
`
`WAG ACQUISITION, LLC
`
`Patent Owner
`
`Patent No. 8,122,141
`
`Issue Date: February 21, 2012
`
`Title: STREAMING MEDIA BUFFERING SYSTEM
`
`____________________________________________________________
`
`DECLARATION OF NATHANIEL POLISH, PH.D.
`
`PAGE 1 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`TABLE OF CONTENTS
`
`I.
`
`Introduction and Qualifications...........................................................................1
`
`II. Understanding of the Governing Law .................................................................3
`
`A. Types of Claims – Independent and Dependent ...............................................3
`
`B. Invalidity by Anticipation or Obviousness........................................................3
`
`C. Secondary or Objective Evidence of Nonobviousness .....................................5
`
`D. Relevant Time Period for the Anticipation and Obviousness Analyses...........6
`
`E. Basis For My Opinion .......................................................................................6
`
`F. Level of Ordinary Skill in the Art in the Relevant Timeframe .........................6
`
`III. State of the Art at the Claimed Priority Date......................................................7
`
`IV. Discussion of the ’011 Patent.........................................................................11
`
`A. Overview .........................................................................................................11
`
`B. Claim Terms of the ’141 Patent ......................................................................12
`
`VI. The Prior Art References................................................................................12
`
`VII. Conclusion.......................................................................................................23
`
`ii
`
`PAGE 2 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`I, Nathaniel Polish, hereby declare the following:
`
`1.
`
`I have been retained by Petitioners to provide my opinions concerning
`
`the validity of claims 1-28 of U.S. Patent No. 8,122,141 (the “’141 patent”). I am
`
`being compensated for my time in preparing this declaration, but my compensation
`
`is not tied to the outcome of this matter and my compensation is not based on the
`
`substance of the opinions rendered here.
`
`I.
`
`Introduction and Qualifications
`
`2.
`
`I have a Ph.D. in Computer Science from Columbia University. I hold
`
`the following four degrees from Columbia University, spanning the years 1980 to
`
`1993:
`
`• Ph.D. in Computer Science, May 1993, Thesis: Mixed Distance
`
`Measures for the Optimization of Concatenative Vocabularies in
`
`Speech Synthesis;
`
`• M.Phil. in Computer Science, December 1989;
`
`• M.S. in Computer Science, December 1987; and
`
`• B.A. in Physics, Columbia College, May 1984.
`I am president of Daedalus Technology Group, Inc., a computer
`
`3.
`
`technology development firm that I co-founded over twenty-five years ago. My
`
`primary business activity is the development of computer-related products, including
`
`small handheld electronic devices and testers, video and messaging systems, as well
`
`1
`
`PAGE 3 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`as large-scale distributed systems.
`
`4.
`
`I have experience in the technical areas of the ’141 patent. For
`
`example, in the early 1980’s, I developed an interactive system using computer
`
`controlled video disks and touch screens. From 1983-1987, I developed high-speed
`
`drivers for several graphical devices and evaluated their applicability for interactive
`
`uses. By 1994, I had developed a proof-of-concept system to compress images of
`
`checks to very small file size.
`
`5.
`
`I have further written an article regarding the technical areas of the
`
`’141 patent, entitled “The Burstware Family of Protocols.”
`
`6.
`
`I am a named inventor on seven United States patents, including U.S
`
`Patent Number 5,963,202 issued on October 5, 1999 and entitled, “System and
`
`Method for Distributing and Managing Digital Video Information in a Video
`
`Distribution Network.”
`
`7.
`
`I am further a member of several professional societies, including the
`
`Institute of Electrical and Electronics Engineers (IEEE), and the Association for
`
`Computing Machinery (ACM).
`
`8.
`
`I have also performed services in patent disputes as an independent
`
`technical expert and consultant and as an expert witness on computer, video, and
`
`software-related cases.
`
`9.
`
`A copy of my curriculum vitae is attached as Exhibit 1011.
`
`2
`
`PAGE 4 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`II. Understanding of the Governing Law
`
`A. Types of Claims – Independent and Dependent
`
`10.
`
`I understand that there are two types of U.S. patent claims: 1)
`
`independent claims and 2) dependent claims. I understand that independent claims
`
`only include the aspects stated in the independent claim. I further understand that
`
`dependent claims include the aspects stated in that dependent claim, plus all the
`
`aspects stated in the other claim(s) from which that dependent claim depends.
`
`B. Invalidity by Anticipation or Obviousness
`
`11.
`
`I understand that a claim is invalid if it is anticipated or obvious. I
`
`understand that anticipation of a claim requires that every element of a claim is
`
`disclosed expressly or inherently in a single prior art reference, arranged as in the
`
`claim. With regard to inherency, I understand that anticipation by inherency
`
`requires that one of ordinary skill in the relevant art would have recognized that the
`
`missing descriptive matter is necessarily present in the subject matter described in
`
`the reference.
`
`12.
`
`I further understand that obviousness of a claim requires that the claim
`
`be obvious from the perspective of a person of ordinary skill in the relevant art, at
`
`the time the invention was made. In analyzing obviousness, I understand that it is
`
`important to understand the scope of the claims, the level of skill in the relevant art,
`
`the scope and content of the prior art, the differences between the prior art and the
`
`claims, and any secondary considerations.
`
`3
`
`PAGE 5 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`13.
`
`I also understand that if a technique has been used to improve one
`
`device, and a person of ordinary skill in the art would recognize that it would
`
`improve similar devices in the same way, using the technique is obvious unless its
`
`actual application is beyond his or her skill. For instance, I understand that the
`
`simple substitution of one known element for another or the mere application of a
`
`known technique to a piece of prior art ready for the improvement is obvious.
`
`14.
`
`In addition, I understand that the United States Supreme Court has said
`
`that “[t]he use of one material instead of another in constructing a known machine is,
`
`in most cases, so obviously a matter of mere mechanical judgment, and not of
`
`invention, unless some new and useful result, an increase of efficiency, or a decided
`
`saving in the operation, is clearly attained.” Hicks v. Kelsey, 85 U.S. 670, 673 (1873).
`
`Moreover, to avoid obviousness, I understand that such a new and useful result,
`
`increase of efficiency, or decided saving in the operation must be unpredictable. KSR
`
`Int’l Co. v. Teleflex Inc., 550 U.S. 398, 416 (U.S. 2007) (“when a patent claims a
`
`structure already known in the prior art that is altered by the mere substitution of one
`
`element for another known in the field, the combination must do more than yield a
`
`predictable result.”).
`
`15.
`
`There may also be a specific “teaching, suggestion or motivation” to
`
`combine any first prior art reference with a second prior art reference. Such a
`
`“teaching, suggestion, or motivation” to combine the first prior art reference with the
`
`4
`
`PAGE 6 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`second prior art reference can be explicit or implicit.
`
`16.
`
`I understand that there are several sources for a “teaching, suggestion
`
`or motivation” to combine references: the nature of the problem to be solved, the
`
`teachings of the prior art, and the knowledge of the persons of ordinary skill in the
`
`art. In addition, market forces or other design incentives may be what produced a
`
`change, rather than true inventiveness. I also know that the application of common
`
`sense and ordinary skill to solve a problem is not patentable.
`
`17.
`
`I understand that when considering invalidity, each claim must be
`
`considered individually.
`
`C. Secondary or Objective Evidence of Nonobviousness
`
`18.
`
`I understand that secondary (or objective) considerations are relevant
`
`to the determination of whether a claim is obvious. Such secondary (or objective)
`
`considerations can include evidence of commercial success caused by an invention,
`
`evidence of a long-felt need that was solved by an invention, evidence that others
`
`copied an invention, or evidence that an invention achieved a surprising result. I
`
`understand that such evidence must have a nexus, or causal relationship to the
`
`elements of a claim, in order to be relevant to the obviousness or non-obviousness of
`
`the claim. I am unaware of any such secondary considerations in relation to the
`
`claims of the ’141 patent.
`
`5
`
`PAGE 7 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`D. Relevant Time Period for the Anticipation and Obviousness Analyses
`
`19.
`
`I also understand that the earliest U.S. application that eventually led to
`
`the ’141 patent was filed on September 12, 2000. Therefore, for the purposes of this
`
`declaration, I have analyzed anticipation and obviousness as of September 2000.
`
`E. Basis For My Opinion
`
`20.
`
`In forming my opinion, I have relied on the ’141 patent claims and
`
`disclosure, the prior art exhibits to the Petition for the IPR of the ’141 patent, and my
`
`belief as to the knowledge of the person of ordinary skill in the relevant art in the
`
`2000 timeframe.
`
`F. Level of Ordinary Skill in the Art in the Relevant Timeframe
`
`21.
`
`In 2000, I believe that a relevant person of ordinary skill in the art at the
`
`time of the ’141 patent (“POSITA”) 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).
`
`22.
`
`These descriptions are approximate, and a higher level of education or
`
`specific skill might make up for less experience, and vice-versa.
`
`23.
`
`I believe I have a sufficient level of knowledge, experience and
`
`education to provide an expert opinion in the field of the ’141 patent, including
`
`what one of ordinary skill in the art would have understood from the prior art in this
`
`field at that time.
`
`6
`
`PAGE 8 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`III. State of the Art at the Claimed Priority Date
`
`24.
`
`Since at least the beginning of the 1990s, digital transmission
`
`technologies had been introduced for digital audio broadcasting and digital video
`
`broadcasting. Ex. 1006, Kozamernik at pp. 1-2. The Internet was recognized as a de
`
`facto worldwide network important for broadcasting activities, having achieved
`
`more than 50% penetration in five major American cities and 50 million users in
`
`four years. Id. at pp. 3, 5. It also was recognized that in contrast to conventional
`
`broadcasting, the Internet allowed the audience to interact with the originator and
`
`shape the content that was delivered. Id. at p. 5. Several protocols, including Real
`
`Time Streaming Protocol (“RTSP”) – a popular application-level protocol known to
`
`enable controlled on-demand delivery of real-time audio and video stream – were in
`
`use for providing real-time services via the Internet. Id. at p. 13.
`
`25. While “download-first-and-then-play” technology was considered
`
`acceptable for short program clips, “streaming” technology, which allowed for
`
`immediate playback, was preferred for on-line radio listening and watching video
`
`clips. Id. at p. 6. During media streaming, a media player, such as RealPlayerTM,
`
`read the media file stream as it was arriving from the network and began playing it
`
`before the rest of the file arrived. Id. In order to make the playback smooth, the
`
`player used a process of buffering. Id. As the player played out the file, it continued
`
`to collect packets in reserve so that if there were minor delays in receiving the
`
`packets, playback was still continuous. Id.
`
`7
`
`PAGE 9 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`26. Buffering was commonly known in the context of streaming media
`
`over the Internet. Transmission over the Internet may not be fully reliable and may
`
`suffer from delay jitter. Id. at pp. 12-13. Delay jitter is the variance in delay of
`
`consecutive packets, which can vary in a non-predictable manner. Id. Buffering
`
`was known to smooth out jitter to enhance playback quality. Id. at p. 12.
`
`27.
`
`A potential side effect of buffering is a short delay while the buffer
`
`fills. The ’141 patent contends that the user must wait for the length of the buffer.
`
`The ’141 patent specifically states that if the user waits ten seconds before playback
`
`starts, then there is enough buffer for ten seconds of interruptions and the buffer
`
`cannot increase during playback. ’141 patent, Ex. 1001 at 3:8-32.
`
`28. But this was not the state of the art. As explained by Kozamernik,
`
`streaming technology allowed for immediate playback. Kozamernik, Ex. 1006 at p.
`
`6. It was well known to increase the transmission rate above the playback rate to
`
`fill the buffer in the first instance and to refill the buffer if there was a low amount
`
`of data in the buffer.
`
`29.
`
`Similar buffers in existence at the time of invention had already dealt
`
`with this very issue. It was well-known to increase the transmission rate above the
`
`playback rate to fill the buffer in the first instance, and to refill the buffer if there
`
`was a low amount of data in the buffer.
`
`30.
`
`For example, Hollfelder, published in 1997, describes a system where
`
`8
`
`PAGE 10 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`the server sends streaming media data at a rate faster than playback to the user,
`
`which is received by a client-side buffer. Hollfelder, Ex. 1010 at 2.1 ¶ 2, 2.3 ¶ 3.
`
`The client maintains a record of the data retrieved and placed into the buffer, and
`
`periodically requests additional data in order to maintain a continuous streaming
`
`presentation to the user. Id. at 3.4 ¶ 17. This is functionally identical to the method
`
`and system described in the ’141 patent and summarized above.
`
`31.
`
`The prior art contains numerous other patents and publications which
`
`comprehensively disclose the various features of the ’141 patent. For example, U.S.
`
`Patent No. 5,822,524 to Chen (Ex. 1002), filed in 1995, along with its published file
`
`history, discloses a server-client architecture in which multimedia files are delivered
`
`from a server buffer to a client-side buffer in the form of digital data packets. Chen
`
`describes a simple transmission concept using a “Water Mark” model. Ex. 1002 at
`
`6:16-54. A bucket may be considered to have 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. See id. When the amount of data (water in the bucket)
`
`falls between the water marks, transmission occurs in the Normal mode. Id. The
`
`Normal mode executes frame level pacing (Id. at 10:3-4) – i.e., transmission at the
`
`playback rate. When the amount of data falls below the low mark, transmission
`
`changes to the Rush mode. Id. at 6:42-47. In the Rush mode, the frame level pacing
`
`is ignored and data is transmitted as fast as possible to maintain enough data in the
`
`9
`
`PAGE 11 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`buffer for playback. Id. at Claims 18, 29, Fig. 6. Chen also describes assigning
`
`packet sequence numbers (serial identifiers) to the data packets making up the
`
`streaming media. Id. at 6:55-7:2. The media player described in Chen uses a
`
`register to maintain a variable last packet sequence number, which is the “packet
`
`sequence number of the last received packet.” Id. at 7:24-32. The user system can
`
`thus request lost packets using the last packet sequence number in the register. Id. at
`
`10:40-50.
`
`32.
`
`U.S. Patent 6,625,656 to Goldhor (Ex. 1007), issued on September 23,
`
`2003, with a priority date of May 4, 1999, also describes a system for continuous
`
`playback of streaming multimedia data through intelligent buffering. The system
`
`controls data output from the buffer based on the playback rate, and controls the
`
`amount of data passing through the buffer in response to changing conditions in the
`
`transmission of data from the server. The server sends data to the buffer at a rate
`
`faster than the playback rate.
`
`33.
`
`“Intelligent Prefetching and Buffering for Interactive Streaming of
`
`MPEG Videos,” published by Susanne Boll et al. in April 2000 (Ex. 1008),
`
`describes a method for pre-buffering streaming MPEG video data for continuous
`
`playback to the user. In Boll, the data is divided into discrete data elements, which
`
`the client buffer requests according to specific identifiers. Boll describes a client
`
`system that maintains a full buffer through repeated requests to the server, to ensure
`
`10
`
`PAGE 12 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`continuous presentation.
`
`34.
`
`“The Burstware Family of Protocols” (Ex. 1009), an article that I
`
`authored in January 1996, also discloses a system for transmitting multimedia data
`
`over a network. In the Burstware system, the server sends specified data elements to
`
`the client buffer through faster-than-real-time (i.e. faster than the playback rate)
`
`transmission channels.
`
`IV. Discussion of the ’141 Patent
`
`A. Overview
`
`35.
`
`The ’141 patent is directed to methods and systems for buffering
`
`streaming media data over the Internet. Ex. 1001 at 1:30-33.
`
`36.
`
`The ’141 patent admits that sending audio and video files via a network
`
`was known in the art. Id. at 4:1-2. The ’141 patent also admits that it was known
`
`for media data stored in a server to be sent over networks to a client buffer to assure
`
`a continuous stream of video. Id. at 2:31-63. The ’141 patent further admits that it
`
`was known to use a pre-buffering technique so that the video can be played with a
`
`minimum of dropouts, and that it was known to transmit video at the rate it is to be
`
`played back on the associated media player. Id. Indeed, the “invention presumes the
`
`existence of a data communications transport mechanism, such as the TCP protocol,
`
`for the reliable delivery of data in an ordered sequence from the source of the media
`
`data to the server, or from the server to the media player software of the user
`
`11
`
`PAGE 13 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`computer. Thus, the delivery of data in the proper sequence is outside the scope of
`
`this invention.” Id. at 5:5-11. Finally, the patent notes the existence of “two types
`
`of encoding schemes …‘Variable Bit Rate’—VBR, and ‘Constant Bit Rate’—CBR
`
`… [where] [t]he standard encoding scheme used for streaming media is CBR ….”
`
`Id. at 5:22-35.
`
`B. Claim Terms of the ’141 Patent
`
`37.
`
`I understand in an Inter Partes Review (“IPR”), a claim receives the
`
`“broadest reasonable construction in light of the specification of the patent in which
`
`it appears.” 37 C.F.R. § 42.100(b). For purposes of the present IPR only, the claim
`
`terms of the ’141 patent are presumed to take on their ordinary and customary
`
`meaning that the term would have to one of ordinary skill in the art. As part of my
`
`analysis of prior art, I was asked to consider the PTAB’s prior constructions
`
`presented in section VII of the petition. My opinions below do not change
`
`depending on whether these constructions, or the ordinary and customary meaning,
`
`are applied.
`
`VI.
`
`The Prior Art References
`
`38.
`
`I have reviewed the prior art references in the Petition, including U.S.
`
`Patent No. 5,822,524 to Chen et al. (“Chen”), U.S. Patent No. 6,389,473 to Carmel
`
`et al. (“Carmel”), Willebeek-LeMair, et al., “Bamba – Audio and Video Streaming
`
`Over the Internet,” March 1998 (“Willebeek) and International Standard ISO/IEC
`
`12
`
`PAGE 14 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`11172 (Exs. 1020-1022) (“ISO-11172”). I have been asked to assume that these
`
`references qualify as prior art to the Challenged Claims.
`
`39. Based on my review of the Chen reference, it is my opinion that each of
`
`the limitations recited in claims 1-2, 4-7, 9-11, 13-16, 18-20, 23-24, and 26-28 are
`
`disclosed by Chen. For example, I have reviewed the description of Chen in the
`
`accompanying Petition and I agree with it.
`
`40. One of skill in the art understands that TCP is – and was in September
`
`2000 – a known internet protocol, and would understand that Chen’s disclosure of a
`
`network that implements TCP protocol would include the internet.
`
`41. One of skill in the art would have understood that Chen’s disclosure of
`
`monitoring packet buffer (31, 33) to control requests for sequential data packets that
`
`make up a multimedia file would continue until all packets for a given multimedia
`
`file had been provided to the client.
`
`42. Chen discloses two processes for keeping track of the last packet
`
`transmitted. In a first process, interruptions in transmission are detected by
`
`assessing whether any packets have been lost. Ex. 1002 at 7:24-32. In a second
`
`process, the server paces transmission in the Normal mode such that the client agent
`
`is not required to send periodic feedback to the server control. Id. at 6:32-39. In this
`
`mode, Chen’s server necessarily tracks the last element sent so as to be able to send
`
`the next sequential element without client feedback.
`
`13
`
`PAGE 15 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`43. One of skill in the art at the time the application for the ’141 patent was
`
`filed would have understood the disclosure of a server (as in Chen or Carmel) to
`
`include a data storage device, memory for storing executable routines and a working
`
`memory area for routines executing on the server, a central processing unit for
`
`executing the instructions, an operating system, and at least one connection to a
`
`communications medium (a network) via a set of communication protocols. In
`
`2000, these were known and necessary components of a server. For example,
`
`Dawna Dwire, Client/Server Computing (McGraw-Hill, Inc. 1993), Ex. 1015, at 31-
`
`32 shows that a POSITA would have understood such a server to include these
`
`components. It describes that a server was known to have storage, memory, one or
`
`more processors, an operating system, and networking software. It also discloses the
`
`use of applications that would be known by one of skill in the art to be stored in
`
`executable routines and executed in working memory. Id.
`
`44.
`
`Similarly, a POSITA would have understood the disclosure of a server
`
`in Chen or Carmel that executes instructions to include a non-transitory machine-
`
`readable medium with a recorded computer program thereon. A POSITA would
`
`have understood that the various instructions executed on these server would be
`
`recorded as a computer program on some non-transitory machine-readable medium.
`
`Id. A POSITA would also understand that multiple servers can act together to
`
`function as a single server.
`
`14
`
`PAGE 16 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`45. A POSITA would have understood Chen’s disclosure of a multimedia
`
`application on client machine 20 that executes instructions to include a non-
`
`transitory machine-readable medium with a recorded computer program thereon. A
`
`POSITA also would have understood that Carmel’s disclosure of clients 30 that
`
`execute instructions to include a non-transitory machine-readable medium with a
`
`recorded computer program thereon. A POSITA would have understood that the
`
`various instructions executed by the client machines would be recorded as a
`
`computer program on some non-transitory machine-readable medium.
`
`46. Chen discloses a client-side buffer which operates without reference to
`
`pointers in a server-side buffer. Rather, Chen maintains a record of the multimedia
`
`data packets on the client-side, and the server responds to user requests for media
`
`data elements identified by a serial identifier.
`
`47. Based on my review of the Chen and Willebeek references, it is my
`
`opinion that each of the limitations recited in claims 8, 17 and 21 are disclosed by a
`
`combination of these references. For example, I have reviewed the description of
`
`this combination in the accompanying Petition and I agree with it.
`
`48.
`
`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 pre-stored video. Doing so would be nothing more than combining
`
`the teachings in a known way to achieve predictable results—it is the use of a known
`
`15
`
`PAGE 17 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`technique (Willebeek’s capture station, and circular buffer queue) to improve similar
`
`known devices (Chen’s system for serving streaming video).
`
`49.
`
`It would have been obvious to configure the combined system so that, if
`
`one of Chen’s user’s 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. Since the circular buffer queue contains a few seconds of
`
`video, Chen would then be able to rush the first packets to the user. 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. Chen, Ex. 1002 at 6:33-39. The teachings of the two systems are
`
`compatible because they both utilize packetized data.
`
`50.
`
`The figure below shows how the modified system conceptually would
`
`be arranged, where a copy of the Willebeek circular buffer is made the server buffer
`
`in the Chen system upon each new user request:
`
`16
`
`PAGE 18 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`51.
`
`The teachings taken from Willebeek include the use of a capture station
`
`and circular buffer to generate a new instance of the server buffer for each new
`
`user—other aspects of Chen could remain the same (e.g., the data would still be
`
`encoded according to Chen’s teachings).
`
`52. Chen’s use of timing information to modify delivery for “frame-level
`
`pacing” (i.e., accounting for differences in frame size) is merely a preferred
`
`embodiment. In this embodiment, in addition to the other features, the system also
`
`paces video based on frame timing—it is not a requisite or essential part of Chen’s
`
`system. See Ex. 1002 at 8:16-32 (referencing “preferred frame-level pacing”). In
`
`Chen’s claims, the use of frame level pacing appears in dependent claims 6, and 8,
`
`indicating the feature is not present in all embodiments.
`
`53. Chen explicitly discloses that extracting frame timing can be done “on
`
`the fly (during multimedia file transmission).” It notes that the frame time can be
`
`“changed at runtime (during transmission) if monitoring by the client agent (30)
`
`17
`
`PAGE 19 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`detects a different playback frame rate.” Nothing about the frame-level pacing
`
`requires prior access to the media file—extraction of the timing information can be
`
`performed on the packets during transmission. If it can be done during transmission
`
`(i.e., after the user has requested a file and while they are viewing it), it could in the
`
`same way be done during transmission of the live packets. A POSITA would have
`
`had no issue with incorporating packetized data from a live feed into the Chen
`
`system.
`
`54.
`
`Thus, it would have been obvious to take Willibeek’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. Upon connection, a copy of
`
`the queue would be made for the user, and that queue would be used as Chen’s
`
`server buffer in all other respects—data would initially be rushed to the user, and
`
`then subsequently provided according to Chen’s protocol. A POSITA 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.” Modifying Chen in this manner would
`
`allow the system to provide access to this recently available data source.
`
`55. Based on my review of the Carmel reference, it is my opinion that each
`
`of the limitations recited in claims 10-11, 13-21 and 23 are disclosed by Carmel.
`
`18
`
`PAGE 20 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`For example, I have reviewed the description of Carmel in the accompanying
`
`Petition and I agree with it.
`
`56. Based on my review of the Carmel and Willebeek references, it is my
`
`opinion that each of the limitations recited in claims 1-2, 4-9, 15, 24, and 26-27 are
`
`disclosed by a combination of these references. For example, I have reviewed the
`
`description of this combination in the accompanying Petition and I agree with it.
`
`57.
`
`It would have been obvious to use Willebeek’s teaching of preloading
`
`and storing data at the client with the system disclosed in Carmel to provide the
`
`benefit of ensuring continuous playback even when network congestion delayed
`
`packet transmission. The systems disclosed in Carmel and Willebeek were known
`
`within the same field (streaming media) and both were directed toward streaming
`
`media from live sources. Ex. 1004 at 277; Ex. 1003 at 6:57-60. To combine the
`
`teachings of Willebeek with Carmel would have involved nothing more than use of a
`
`known technique (Willebeek’s client storage) to improve a similar known device
`
`(the Carmel server-client streaming architecture) in the same way. The application
`
`of Willebeek’s teaching of client storage would have predictable results—ensuring
`
`continuous playback while still allowing for high quality content to be provided,
`
`even when insufficient bandwidth exists due to network congestion. Ex. 1004 at
`
`270.
`
`58. Carmel discloses a system that operates without reference to pointers in
`
`19
`
`PAGE 21 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`a server-side buffer. Ex. 1003 at 7:50-58. Rather, the client in Carmel uses the
`
`indices associated with the media frames to maintain a record of the slices on the
`
`client-side, and the server responds to requests for slices identified by index.
`
`59.
`
`The use of TCP protocol for data communication on a network requires
`
`that requests for data specify the sequence number of the desired data packet. This
`
`is accomplished by having the client receiver return a “window” of acceptable
`
`packet sequence numbers to the server in order to specify which data packets are to
`
`be sent by the server. Thus, under normal conditions the specification of the
`
`window serves as a request to transmit packets up to a particular sequence number.
`
`60.
`
`I understand that the meaning of a term in a reference can be explained
`
`using a secondary reference. As shown in “Transmission Control Protocol
`
`[(“TCP”)] – DARPA Internet Program Protocol Specification,” dated September
`
`1981, (Ex. 1014), when using TCP, the receiver governs data flow by returning a
`
`window of acceptable packet sequence numbers that indicates the packets (“octets”)
`
`the server should transmit. See, Ex. 1014 at p. 24 (“A fundamental notion in the
`
`design is that every octet of data sent over a TCP connection has a sequence number.
`
`Since every octet is sequenced, each of them can be acknowledged.”); p. 4 (“TCP
`
`provides a means for the receiver to govern the amount of data sent by the sender.
`
`This is achieved by returning a ‘window’ with every ACK indicating a range of
`
`acceptable sequence numbers beyond the last segment successfully received. The
`
`20
`
`PAGE 22 of 26
`
`PETITIONERS' EXHIBIT 1005
`
`
`
`window indicates an allowed number of octets that the sender may transmit before
`
`receiving further permission.”); p. 10 (“To govern the flow of data between TCPs, a
`
`flow control mechanism is employed. The receiving TCP reports a ‘window’ to the
`
`sending TCP. This window specifies the number of octets, starting with the
`
`acknowledgment number, that the receiving TCP is currently prepared to receive.”);
`
`p