`
`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,364,839
`
`Issue Date: Jan. 29, 2013
`
`Title: STREAMING MEDIA DELIVERY SYSTEM
`
`DECLARATION OF NATHANIEL POLISH, PH.D.
`
`PAGE 1 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`TABLE OF CONTENTS
`
`I.
`II.
`
`Introduction and Qualifications.......................................................................1
`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
`
`Analysis.................................................................................................6
`Basis for My Opinion............................................................................6
`E.
`Level of Ordinary Skill in the Art in the Relevant Timeframe.............6
`F.
`State of the Art at the Claimed Priority Date ..................................................7
`III.
`IV. Discussion of the ‘839 patent ..........................................................................9
`V.
`Claim Terms of the ‘839 patent.....................................................................11
`VI.
`The Prior Art References...............................................................................12
`A.
`Chen.....................................................................................................12
`B.
`Chen and ISO-11172...........................................................................15
`C.
`Chen and Willebeek ............................................................................18
`D.
`Chen and Cannon ................................................................................23
`E.
`Chen File History ................................................................................25
`VII. Conclusion.....................................................................................................28
`
`i
`
`PAGE 2 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`I, Nathaniel Polish, hereby declare the following:
`
`1.
`
`I have been retained by Petitioners to provide my opinions concerning
`
`the validity of claims 1-21 of U.S. Pat. No. 8,364,839 (“the ‘839 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,
`
`1
`
`PAGE 3 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`including small handheld electronic devices and testers, video and messaging
`
`systems, as well as large-scale distributed systems.
`
`4.
`
`I have experience in the technical areas of the ‘839 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 highspeed
`
`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
`
`‘839 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). Attached hereto as Appendix A, is a true and
`
`correct copy of my Curriculum Vitae describing my background and experience.
`
`8.
`
`I have also performed services in patent disputes as an independent
`
`
`
`2
`
`PAGE 4 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`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 1012.
`
`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.
`
`11.
`
`Invalidity by Anticipation or Obviousness
`
`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
`
`
`
`3
`
`PAGE 5 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`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.
`
`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
`
`
`
`4
`
`PAGE 6 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`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 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.
`
`18.
`
`Secondary or Objective Evidence of Nonobviousness
`
`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,
`
`
`
`5
`
`PAGE 7 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`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 ‘839 patent.
`
`D. Relevant Time Period For The Anticipation and Obviousness
`Analysis
`
`19.
`
`I also understand that the earliest U.S. application that eventually led
`
`to the ‘839 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 ‘839 patent claims and
`
`disclosure, the prior art exhibits to the Petition for the IPR of the ‘839 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 ‘839 patent (“POSITA”) would have had a B.S. degree in computer
`
`
`
`6
`
`PAGE 8 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`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 ‘839 patent, including
`
`what one of ordinary skill in the art would have understood from the prior art in
`
`this field at that time.
`
`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. 1011, 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 was also 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
`
`
`
`7
`
`PAGE 9 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`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.
`
`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 ‘839 patent contends that the user must wait for the length of the buffer
`
`stating that if the user waits ten seconds before playback starts then there is enough
`
`
`
`8
`
`PAGE 10 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`buffer for ten seconds of interruptions and the buffer cannot increase during
`
`playback. ‘839 patent, Ex. 1001 at 2:35-3:4.
`
`28. But this was not the state of the art. As explained by Kozamernik,
`
`streaming technology allowed for immediate playback. Kozamernik, Ex. 1010 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.
`
`IV. Discussion of the ‘839 patent
`
`29. The ‘839 patent is directed to systems and methods for delivering
`
`streaming media on the Internet. ‘839 patent, Ex. 1001 at 1:34-46.
`
`30. The Background section concedes that sending audio and video files
`
`via a network was known in the art, as was the use of buffers both at the server (id.
`
`at 1:51-59) and on a user computer (id. at 2:24-27). In these known systems,
`
`video can be sent at the rate it is to be played back, and the buffers allow content to
`
`play with minimal dropouts. Id. at 2:24-27, 2:45-48. The ‘839 patent asserts that
`
`there was a need for improved systems and methods to facilitate “continuous
`
`transmission of streaming content, respond on demand without objectionable
`
`buffering delay, and perform without disruption or dropouts.” Id. at 3:24-29.
`
`According to the ‘839 patent, these objectives are addressed by “(a) sending initial
`
`
`
`9
`
`PAGE 11 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`streaming media elements to the user system at a sending rate more rapid than the
`
`playback rate, to fill the playback buffer; and (b) after the user buffer has been
`
`filled, sending further streaming media data elements to the user system at about
`
`the playback rate.” Id. at 3:38-43.
`
`31. The ‘839 patent uses the server’s built-in transport mechanism, e.g.,
`
`the server’s Transmission Control Protocol (“TCP”) stack, as a control mechanism.
`
`Id. at 8:9-13; see also IPR2015-01036, Paper 8 at 5-6. A server buffer transfers
`
`data, via the transport mechanism, to the client buffer and can send as much data as
`
`the transport mechanism will accept. Id. at 10:23-33. On a new connection, the
`
`server sends content to rapidly fill a user buffer. Id. at 8:31-44. After the initial
`
`fast transfer, the system enters a steady state in which it continues to fill at the
`
`playback frame rate. Id. at 7:65-8:4. If an interruption occurs, the TCP can
`
`respond in two ways. First, for moderate interruptions, the user buffer will become
`
`depleted and the server will attempt to send data at a faster rate to rebuild the user
`
`buffer while the video plays. Id. at 9:56-10:10. For more severe interruptions, the
`
`transport mechanism will stop accepting data for transmission, and will resend at a
`
`higher rate after the connection is restored. Id. at 10:11-37.
`
`32. The ‘839 patent includes three independent claims (1, 8 and 15),
`
`which are of substantially similar scope. Each includes an initial step of sending
`
`
`
`10
`
`PAGE 12 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`multimedia data from a server to a client at a rate more rapid than a playback rate,
`
`and thereafter sending such data at a playback rate. Each also includes a step of
`
`detecting whether there are any interruptions in the transmission of multimedia
`
`data from the server to the client. This latter limitation was added into each of the
`
`independent claims before allowance. ‘839 patent File History, Ex. 1002,
`
`Examiner’s Amendment at 839FH058-59. Independent claims 8 and 15 include
`
`two additional limitations not found in independent claim 1: (i) reloading the
`
`server buffer with a specified amount of streaming media elements in the event an
`
`interruption is detected, and (ii) after reloading, continuing to supply media data
`
`elements to the server buffer at about the playback rate until there are no further
`
`streaming media data elements to be sent.
`
`V. Claim Terms of the ‘839 patent
`
`33.
`
`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). I understand the claim terms of the ‘839
`
`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.
`
`
`
`11
`
`PAGE 13 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`VI. The Prior Art References
`
`34.
`
`I have reviewed the prior art references in the Petition including
`
`U.S. Patent No. 5,822,524 to Chen (Ex. 1004) (“Chen”), International Standard
`
`ISO/IEC 11172 (Exs. 1005-1008) (“ISO-11172”), Willebeek-LeMair, M. H., K.
`
`G. Kumar, and E. C. Snible. “Bamba--Audio and video streaming over the
`
`Internet.” 42 IBM Journal of Research and Development¸ Vol. 42, No. 2 at 269,
`
`Nov. 1998 (“Willebeek”); U.S. Patent No. 6,014,706 to Cannon et al.
`
`(“Cannon”); File History of U.S. Patent No. 5,822,524 to Chen et al. (“Chen File
`
`History”)
`
`A. Chen
`
`35. Chen discloses a server-client architecture in which multimedia files
`
`are delivered from a server buffer (stream buffer 11, 18) to a client-side buffer
`
`(packet buffer 31, 33) in the form of digital data packets, shown in FIG. 1 below.
`
`Chen, Ex. 1004 at 5:17-34.
`
`Chen describes three transmission modes for sending multimedia data to the client:
`
`
`
`
`
`12
`
`PAGE 14 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`NORMAL, RUSH, and PAUSE. Id. at 6:1-15. When there is too little data in the
`
`packet buffer 33, the transmission mode uses the RUSH mode. Id. When the
`
`amount of data in the packet buffer 33 is between high and low “watermarks,” the
`
`transmission mode is in the NORMAL mode. Id. When there is too much data in
`
`the packet buffer 33, the transmission mode enters the PAUSE mode. Id. at 6:40-
`
`54.
`
`36. Chen teaches that the mode that is used at the start of transmission is
`
`the RUSH mode. In Chen, the client agent 3 sends a request to the command
`
`processor 15 of the server to initiate a file open request. Id. at 9:31-48. A
`
`response command is sent to the client agent, and if it is accepted, the server sets
`
`up the necessary structure including the stream buffer and signals the
`
`transmission scheduler 13 at the server to begin transmitting frames. Id. at 9:41-
`
`48. At this point, the client buffer is necessarily empty—no files have been
`
`transmitted. Accordingly, a POSITA would understand that Chen will operate in
`
`RUSH mode, which is the mode used when “a low amount of data exists in the
`
`client agent’s packet buffer.” Id. at 10:14-15.
`
`37. Chen switches to NORMAL mode when the client agent’s packet
`
`buffer crosses above the low water mark. Id. at 6:52-54. In NORMAL mode, the
`
`scheduler 13 at the server spaces transmission so that the data for a single video
`
`
`
`13
`
`PAGE 15 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`frame is transmitted in the time of a single video frame (i.e., at playback rate). Id.
`
`at 6:31-39.
`
`38. Chen also discloses filling a server buffer or moving a data window
`
`through a server buffer at about the playback rate. Chen’s server includes a
`
`stream buffer, and in a claimed embodiment, the stream buffer is small having
`
`only 1-5 frames. Chen, Ex. 1004 at 5:17-34; Claims 16, 27 and 42. Thus, in the
`
`NORMAL mode where transmission is paced at the playback rate, the stream
`
`buffer fills and moves a data window through the 1-5 frame buffer at “about” the
`
`playback rate. For example, when there is a single frame stream buffer, and the
`
`system is in NORMAL mode transmitting packets from the stream buffer at the
`
`playback rate, the data window is necessarily moving through the stream buffer at
`
`“about” the playback rate. Id.
`
`39. Chen discloses detecting interruptions in two ways. First, Chen
`
`describes detecting a lost packet and transmitting a “lost packet request” so that
`
`the lost packets are retransmitted “as soon as possible.” Id. at 10:40-50. Second,
`
`when an interruption is sufficiently severe to cause the user buffer to fall below
`
`the low water mark, Chen will detect this interruption in the data stream and
`
`respond by entering Rush mode to refill the buffer. Id. at 6:42-46. This second
`
`interruption detection and response is the same interruption detection and
`
`
`
`14
`
`PAGE 16 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`response described in the ‘839 patent at, for example, 9:60-67. See also 15:44-
`
`48.
`
`40. A POSITA at the time the application for the ‘839 patent was filed
`
`would have understood Chen’s disclosure of a server (an IBM PC Server, for
`
`example) 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 components of a server. For example,
`
`Dawna Dwire, Client/Server Computing (McGraw-Hill, Inc. 1993), Ex. 1017, at
`
`31-32 shows that one of ordinary skill in the art would have understood that
`
`servers to include these components. It describes that a server is 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.
`
`Chen also discloses the use of the TCP protocol, which in September 2000 was a
`
`known protocol used for Internet communications.
`
`B. Chen and ISO-11172
`
`41. Based on my review of Chen (Ex. 1004), the ISO-11172 references
`
`
`
`15
`
`PAGE 17 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`(Exs. 1005-1007), it is my opinion that each of the limitations recited in claims 3,
`
`10, and 17 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.
`
`42.
`
`ISO-11172 was published on August 1, 1993. Ex. 1006 at 1. ISO-
`
`11172 is the specification the well-known international standard for the encoding
`
`and decoding of audio and video streams, commonly known as MPEG-1. ISO-
`
`11172 is, and was in 2000, a well-known document that a POSITA would have
`
`been aware of.
`
`43.
`
`It was well known at the time of the invention that multimedia data
`
`could be encoded at either a constant bit rate or a variable bit rate. Claims 3, 10 and
`
`17 therefore only offer an obvious variation over the limitations of the respective
`
`independent claims. Chen discloses the MPEG-1 standard in the Summary of the
`
`Invention as one standard for providing the building blocks of the multimedia data
`
`stream. ISO-11172 is the MPEG-1 standard and discloses both a constant bit rate
`
`and a variable bit rate. See ISO-11172-1, Ex. 1005 at p. 22; ISO-11172-2, Ex. 1006
`
`at p. 27 (discussing flags having differently defined values for fixed/constant bit
`
`rate operation and variable/non-constant bit rate operation). The flags that indicate
`
`different defined values for constant versus variable bit rate operation are
`
`
`
`16
`
`PAGE 18 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`indicative that the standard encompasses both encoding schemes.
`
`44. Accordingly, although constant bit rate encoding is not explicitly
`
`referenced, one of ordinary skill in the art would understand that Chen’s reference
`
`to MPEG-1 implies that the scope of the disclosure encompasses both constant and
`
`variable bit rate embodiments.
`
`45. Further, if not inherent to Chen, a POSITA would be motivated to
`
`look to ISO-11172 to modify the teachings of Chen to support constant bit rate
`
`encoded media data - one of the well-known known options of MPEG-1 – for the
`
`purposes of supporting a wider variety of media data. Such a modification would
`
`be a mere design choice and within the ordinary skill in the art.
`
`46.
`
`In addition, 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. Chen, Ex. 1004 at 7:24-32. In
`
`particular, Chen describes the use of a register for maintaining the last packet 28
`
`sequence number that has arrived in order to assess whether the next packet
`
`received is sequential. Id. If not, then the system of Chen detects a packet loss.
`
`Id. 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. Thus, in this mode, Chen’s server necessarily tracks the last
`
`
`
`17
`
`PAGE 19 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`element sent so as to be able to send the next sequential element without client
`
`feedback.
`
`C. Chen and Willebeek
`
`47. Based on my review of Chen (Ex. 1004) and Willebeek (Ex. 1008), it
`
`is my opinion that each of the limitations recited in claims 5, 12, and 19 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. Willebeek was published in the IBM Journal of Research and
`
`Development, Volume 42 No. 2 in March 1998. Ex. 1008 at 269. The IBM
`
`Journal of Research and Development is, and was in 1998, a well-known journal in
`
`the field—it would have been known to a POSITA, and would have been available
`
`such that a person interested and ordinarily skilled in the subject matter exercising
`
`reasonable diligence could have located it in 1998.
`
`49. Chen describes opening files from a storage subsystem 12. See FIG.
`
`1. In a preferred embodiment, shown in FIG. 4, a parser 62 extracts frame-by-
`
`frame timing information from a multimedia file, placing the timing in an index
`
`file 63, which is used by the server control 64 to pace transmission. Chen, Ex.
`
`1004 at 8:43-55. Chen states that the parser can extract the frame information
`
`beforehand or on the fly (during multimedia file transmission). Id. at 8:50-52.
`
`
`
`18
`
`PAGE 20 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`50. Willebeek describes a system for streaming audio and video over the
`
`Internet, similarly using buffers at a server and client and packetized data.
`
`Willebeek further discloses a way to provide the system, which can use stored
`
`video like Chen, with a live feed. Specifically, Willebeek describes the use of a
`
`capture station that receives audio and video inputs, converts the data from analog
`
`to digital, compresses and packetizes it. Willebeek, Ex. 1008 at 277-278; Figure 6.
`
`The packets are then transferred to a server with a buffer (the “reflector”).
`
`Willebeek maintains a circular buffer queue containing the most recent several
`
`seconds of a live transmission. Id. at 278; Figure 6. When a new user requests live
`
`video, the server produces a new copy of the circular buffer and that copy is used
`
`as that user’s server buffer. Id.; see also Figures 6-7.
`
`51.
`
`It would have been obvious to a POSITA 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 technique (Willebeek’s capture station, and
`
`circular buffer queue) to improve similar known devices (Chen’s system for
`
`serving streaming video and server buffer).
`
`52. More specifically, it would have been obvious to a POSITA to
`
`
`
`19
`
`PAGE 21 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`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. 1004 at 6:33-39. The teachings of the two systems are especially
`
`compatible because they both utilize packetized data. The figure below shows how
`
`the modified system would conceptually be arranged, where a copy of a circular
`
`buffer is made the server buffer in the Chen system upon each new user request:
`
`53. The teachings taken from Willebeek include be the use of a capture
`
`20
`
`
`
`
`
`PAGE 22 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`station and circular buffer to generate a new server buffer for each new user—other
`
`aspects of Chen could remain the same (e.g., the data would still be encoded in
`
`packets according to Chen’s teachings).
`
`54.
`
`I understand that Patent Owner has argued that Chen could not be
`
`compatible with packets from a live feed because Chen needs time to analyze the
`
`multimedia files to determine their timing specifications to work, and so Chen
`
`could not work with live video. This is incorrect for two reasons. First, Chen’s
`
`use of timing information to modify delivery for “frame-level pacing” (i.e.,
`
`accounting for differences in frame size) is described as 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
`
`Chen, Ex. 1004 at 8:16-32 (referencing “preferred frame-level pacing”).
`
`55. Second, even if frame timing were required, Chen explicitly discloses
`
`that extracting frame timing can be done “on the fly (during multimedia file
`
`transmission).” Id. at 8:50-52. It notes that the frame time can be “changed at
`
`runtime (during transmission) if monitoring by the client agent (30) detects a
`
`different playback frame rate.” Id. at 8:50-55. Thus, 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 extraction can be done
`
`
`
`21
`
`PAGE 23 of 30
`
`PETITIONERS' EXHIBIT 1003
`
`
`
`during transmission (i.e., after the user has requested a file and while they are
`
`viewing it), then a POSITA would understand it could in the same way be done
`
`during transmission of the live packets. In either case, it involves examining the
`
`packet-level information that is being placed in the server buffer. Thus, a POSITA
`
`would have no issue with incorporat