throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket