`
`Case IPR2016-01656
`Patent 8,122,141
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________________________________
`
`
`
`I.M.L. SLU,
`Petitioner
`
`
`
`v.
`
`
`
`WAG ACQUISITION, LLC
`Patent Owner
`
`
`
`U.S. Patent No. 8,122,141 B2
`
`
`
`_______________________________________
`
`Inter Partes Review Case No. IPR2016-01656
`_______________________________________
`
`
`
`PATENT OWNER RESPONSE
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`TABLE OF CONTENTS
`
`I.
`
`INTRODUCTION AND SUMMARY OF ARGUMENT .......................... 2
`
`II. CHEN .............................................................................................................. 3
`
`A. Chen FH ............................................................................................... 5
`
`B. Willebeek .............................................................................................. 5
`
`C. Carmel .................................................................................................. 6
`
`III. CLAIM CONSTRUCTION – “IN A FORMAT CAPABLE OF
`
`BEING SERVED TO USERS BY SAID SERVER” .................................. 7
`
`IV. DISCUSSION ................................................................................................. 9
`
`A. Chen does not disclose a routine to store and serially identify
`
`sequential data elements in a format capable of being served
`
`to users .................................................................................................. 9
`
`B. Willebeek Does Not Cure Fundamental Deficiencies of Chen
`
`and Chen FH With Respect to Claim 21 ......................................... 13
`
`C. Carmel Does Not Cure Fundamental Deficiencies of Chen and
`
`Chen FH With Respect to Claim 21 ................................................ 16
`
`V. CONCLUSION ............................................................................................ 18
`
`
`
`
`
`
`
`i
`
`
`
`
`
`EXHIBIT LIST
`
`Case IPR2016-01656
`Patent 8,122,141
`
`Exhibit Number Description
`
`2003
`
`2004
`
`
`
`Declaration of Keith J. Teruya (“Teruya Decl.”)
`
`Curriculum vitae of Keith J. Teruya
`
`
`
`ii
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`Patent Owner WAG Acquisition, L.L.C. (“Patent Owner” or “WAG”)
`
`respectfully submits this Response in accordance with 37 C.F.R. § 42.120,
`
`responding to the Petition for inter partes review (the “Petition”) filed by I.M.L.
`
`SLU (“Petitioner”) regarding claims 19-23 of U.S. Patent No. 8,122,141 (Ex.
`
`1001) (the “’141 Patent”). Accompanying this response is the declaration of Keith
`
`J. Teruya, who addresses certain technical issues in connection herewith (Ex.
`
`2003) (“Teruya Decl.”).
`
`The Board has instituted review of claims 19, 20, and 23 as being anticipated
`
`by U.S. Patent No. 5,822,524 to Chen et al. (“Chen”)(Ex. 1002), claims 21 and 22
`
`as being obvious over Chen in view of the File History of Chen (“Chen FH”)(Ex.
`
`1010) and Willebeek-LeMair, et al., “Bamba – Audio and Video Streaming Over
`
`the Internet,” IBM Journal of Research and Development, Vol. 42, No. 2, March
`
`1998 (“Willebeek”)(Ex. 1004), while claim 22 is subject to review as obvious over
`
`Chen in view of Chen File History, Willebeek, and ISO-11172 (Exs. 1005-07), and
`
`claim 21 is further subject to review as obvious over Chen in view of U.S. Patent
`
`No. 6,389,473 to Carmel et al. (“Carmel”)(Ex. 1003).
`
`Patent Owner continues to assert that the instant Petition is time-barred
`
`based upon Petitioner’s relationship to one or more real parties in interest or
`
`privies. Discovery concerning this issue is on-going and Patent Owner will be
`
`seeking leave to file a motion to terminate by reason of Petitioner’s failure to name
`
`
`
`these real parties in interest, and/or by Petitioner being barred under 35 U.S.C. §
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`315(b) due to a real party in interest, or a privy of Petitioner, having been served
`
`with a complaint for infringing the patent challenged herein more than a year prior
`
`to the filing date of the instant Petition.
`
`I.
`
`INTRODUCTION AND SUMMARY OF ARGUMENT
`
`Claims 19-23 of the ’141 Patent are directed to a computer program for
`
`preparing streaming media content for transmission by a server, in which one or
`
`more media player clients receive and play the streaming media over an Internet
`
`Protocol network from the server via a “pull” mechanism – where transmission of
`
`data elements within the stream is requested by the client. Streaming media
`
`transmission occurs in response to repeated requests by the client for serially
`
`identified media data elements comprising the program stream. The media data
`
`elements are served in response to those client requests.
`
`The Petition’s references, including the primary references Chen, Chen FH,
`
`Willebeek, and Carmel, do not use repeated client requests for media data elements
`
`in order to transmit a multimedia program. As discussed below, Chen’s main
`
`transmission mechanism uses a server “push” mechanism, and specific requests are
`
`used only to fill-in missing packets. Because Chen’s packets are relatively small, a
`
`person having ordinary skill in the art (“PHOSITA”) in the 2000 time frame, the
`
`priority date of the ’141 Patent, would understand that such packets would be
`
`
`
`2
`
`
`
`unsuitable for “pull-based” streaming as contemplated in claims 19-23 of the ’141
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`Patent. The secondary references of Willebeek and Carmel relied upon by the
`
`Petition do nothing to cure this fundamental deficiency of Chen.
`
`II. CHEN
`
`Chen, the primary reference relied upon, is directed to just-in-time delivery
`
`of multimedia content from a server to a client that entails minimum latency and
`
`overhead, while ensuring that “the final picture on the client machine monitor [is]
`
`of high quality, i.e., not being jerky; and without the use of additional memory or
`
`other additional hardware.” (Chen, 3:36-38; see also id., 5:24-27.) Fig. 1 from
`
`Chen is reproduced below:
`
`
`
`As noted by the Board, Chen achieves its objectives by way of frame level
`
`pacing, which by default sends each frame of the transmission at scheduled times
`
`such that the streaming in the aggregate takes place at about the playback rate. (See
`
`Chen, 8:43-55.) Server 21 is responsible for pacing “its transmission so that the
`
`data for a single video frame is transmitted in the time of a single video frame,”
`
`setting up and maintaining various registers for each frame of the media in order to
`
`
`
`3
`
`
`
`do so. (Id., 6:34-37; see also id., 9:49-10:31 & Fig. 6.) Chen then further regulates
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`this flow using a client-side feedback mechanism, in which the client monitors its
`
`receive buffer 31 using a “water mark” system, and triggers transitions of server 21
`
`into one of “NORMAL,” “RUSH,” and “PAUSE” modes as required based upon
`
`changes in these water mark levels. (See id., 6:1-15.) RUSH mode temporarily
`
`overrides the normal frame-level pacing such that the server reads from local disk
`
`and sends all frames as fast as it can until it receives a command from the client to
`
`switch out of RUSH mode. (See, e.g., id., 12:26-27.)
`
`Chen contemplates server 21 as running primarily in NORMAL mode for
`
`transmission efficiency purposes (that is, between the low and high water marks),
`
`since, when in NORMAL mode, “no need exists for the client agent (30) to send
`
`periodic feedback to the server control (1).” (Id., 6:38-39.) With the client buffer
`
`kept at a mid-water mark level (i.e., between the high and low water marks), Chen
`
`seeks to ensure that “the packet buffer (33) [has] enough data: to minimize the
`
`possibility of not having the requested data, and (ii) still have enough free buffer
`
`space (memory space) to receive new data packets.” (Id., 6:4-7.)
`
`This technique, for example, when used over UDP (which performs no
`
`delivery check), may result in lost packets, which losses may be either ignored or
`
`corrected. (Id., 7:18-23.) As noted by the Board, in a transmission mode in which
`
`transmission errors are sought to be corrected, “the client [of Chen] maintains a list
`
`
`
`4
`
`
`
`of lost packets that includes the packet sequence number and time-out value. The
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`client sends a retransmission request for the lost packet and removes that packet
`
`from the missing-packet list if the packet arrives correctly before the expiration of
`
`the time-out value; if not, the client sends another retransmission request or gives
`
`up obtaining the missing packet.” (Institution of Inter Partes Review, Case
`
`IPR2016-01656, Paper 11, at 13)(“Institution Decision.”) As also noted by the
`
`Board, “there is no disclosure in Chen to transmit requests to the server to send one
`
`or more data elements, specifying the identifiers of the data elements, as said
`
`media player requires in order to maintain a sufficient number of media data
`
`elements in the media player for uninterrupted feedback.” (Institution Decision
`
`13)(internal quotations and citations omitted.)
`
`A. Chen FH
`
`Chen FH concerns a “Quick Video Server” (“QVS Sever”) document that
`
`allegedly describes a commercial embodiment of Chen that includes RUSH,
`
`NORMAL, and PAUSE modes. (See Chen FH 86.) According to Chen FH, when
`
`the QVS Server receives a file open request from the client, the server “[r]ead[s]
`
`data from disk and rush [sic] them to CA.” (Id.)
`
`B. Willebeek
`
`Willebeek discloses a client-server arrangement for streaming video data,
`
`including live video. Fig. 6 from Willebeek is reproduced below:
`
`
`
`5
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`
`
`In Willebeek, a capture station packetizes analog data, which it then
`
`forwards to a reflector. The reflector streams this packetized data to its clients on a
`
`first-in-first-out basis, with each client having its own circular buffer in the
`
`reflector. When a new playback station connects to the reflector, a copy of the
`
`circular buffer is made for the joining client. (See Willebeek 277-78.)
`
`C. Carmel
`
`Carmel discloses a system in which a source computer provides live or
`
`prerecorded media to a server, which then streams this media to a plurality of
`
`clients. With respect to the instituted ground based on Chen in view of Carmel,
`
`Carmel is cited only for the fact that it provides a live source feed: “For the reasons
`
`explained in Section X.D.2, infra [alleged obviousness over Chen in view of
`
`Wiilebeek], it would have been obvious to provide the Chen system with a live
`
`source feed for the same reasons that it would have been obvious to combine Chen
`
`with Willebeek to stream live broadcasts.” (Petition 53.)
`
`
`
`6
`
`
`
`III. CLAIM CONSTRUCTION – “IN A FORMAT CAPABLE OF BEING
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`SERVED TO USERS BY SAID SERVER”
`
`Claim 19 recites that the sequential data elements served to the client player
`
`are “in a format capable of being served to users by said server.” (’141 Patent,
`
`14:57-58 (emphasis added)). Patent Owner asserts that the proper construction of
`
`the italicized portion in this claim language means a format whose characteristics
`
`make it possible to serve the multimedia program comprised of those elements via
`
`the recited “pull” mechanism in order to achieve uninterrupted playback.
`
`The Petition does not seek a construction of this language. It merely quotes
`
`this language but fails to address what the claimed format limitation requires.
`
`The words in question appear in the following claim context:
`
`19. A non-transitory machine-readable medium on which there has
`
`been recorded a computer program for use in operating a computer to
`
`prepare streaming media content for transmission by a server
`
`wherein said server responds to user requests for media data elements
`
`identified by a serial identifier, said program recorded on said non-
`
`transitory machine readable medium comprising a routine to store and
`
`serially identify sequential data elements comprising said streaming
`
`media content, in a format capable of being served to users by said
`
`server.
`
`(’141 Patent, claim 19 (emphasis added).)
`
`
`
`7
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`Claim 19 and its dependents are directed at preparing streaming media for
`
`pull transmission by breaking the streaming media into serially identified elements
`
`and appropriately formatting the elements for transmission. The meaning of the
`
`words “being served” in claim 19 is informed by the preamble, which refers to a
`
`server for streaming media that operates to stream the media by responding to user
`
`requests for serially identified elements of the stream. The antecedent for the words
`
`“said server” is the server that is going to stream the content for which the software
`
`described in claim 19 is preparing the content by breaking this content into serially
`
`identified chunks.
`
`Claim 19 contemplates preparing the media for a server that will serve the
`
`entire stream, defined in the specification as “Internet streaming media composed
`
`of a plurality of time-sequenced data elements.” (’141 Patent, 5:55-56.) A “format
`
`capable of being served to users by said server” means a format that can be served
`
`by the server for which the stream is being prepared in accordance with claim 19.
`
`The claim also recites that “said server” is one that responds to user requests for
`
`media data elements identified by a serial identifier. It therefore follows that the
`
`formatted elements as recited in the claim must be capable of being requested, sent,
`
`and transmitted to support what is understood as “streaming” a plurality of “time-
`
`sequenced data elements” comprising a multimedia program in the uninterrupted
`
`manner normally expected of such streaming.
`
`
`
`8
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`Hence, a PHOSITA would understand that the broadest reasonable
`
`interpretation of the term “capable of being served to users by said server,” means
`
`a data format that is capable of being served in accordance with the features of a
`
`“pull” server; that is, a format whose characteristics make it possible to serve the
`
`multimedia program comprised of those elements via the recited “pull” mechanism
`
`(client request by specified serial identifier) in order to achieve uninterrupted
`
`playback.
`
`IV. DISCUSSION
`
`When properly construed, claims 19-23 are patentable over Chen, Chen FH,
`
`Willebeek, and Carmel.
`
`A. Chen does not disclose a routine to store and serially identify
`
`sequential data elements in a format capable of being served to
`
`users
`
`Claim 19 recites a computer readable medium “comprising a routine to store
`
`and serially identify sequential data elements comprising said streaming media
`
`content, in a format capable of being served to users by said server.” (’141 Patent,
`
`claim 19 (emphasis added).)
`
`Chen’s packets are not “sequential data elements comprising said streaming
`
`media content, in a format capable of being served to users by said server” because
`
`
`
`9
`
`
`
`they are too small to be capable of being served as intended in Chen’s lost-packet
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`mechanism. (See Teruya Decl. ¶¶ 11-12.)
`
`More specifically, Chen addresses video content in MPEG formats, which
`
`comprises frames of varying sizes. (See Chen, 2:56-67.) Chen envisions formats at
`
`a frame rate of 30 frames per second. (See id., 6:32-37.) Frame sizes “may vary by
`
`as much as a factor of 10.” (Id., 2:62-63). Chen transmits video frames that have
`
`been “packetized” into packets. (Id., 7:3-4.) A packet is a subunit of a frame. (See
`
`id., Fig. 4 (showing Data Packet 66 as a part of Frame Data 65); 6:64-67; Teruya
`
`Decl. ¶ 13.)
`
`A PHOSITA would not have viewed “pull” packet sizes of less than a frame
`
`(with each frame getting played out in 33 ms (1/30s)) as an operable
`
`implementation for transmission of an entire stream via a client-side pull
`
`mechanism. (See Teruya Decl. ¶¶ 14, 18-19.) For example, assuming the extreme
`
`best case of only two packets per frame for Chen, each packet would have to be
`
`requested, processed and returned within less than 17 ms. In the worst case of large
`
`frames at the high end of Chen’s 10:1 size estimate, packet transmission times
`
`would be an order of magnitude smaller, and unworkable given the signaling
`
`overhead of requesting each packet by serial identifier in a round-trip network
`
`transaction. (Id.)
`
`
`
`10
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`Anticipation by Chen is therefore ruled out, as Chen’s packets are not “in a
`
`format capable of being served to users” in the “pull” configuration contemplated
`
`by claim 19.
`
`Furthermore, using units of packets that are smaller than a frame (and
`
`therefore unsuitable for claim 19 for the reasons noted above) is not merely a
`
`design choice in Chen, it is a necessity, driven by the central design and teaching
`
`of Chen to send multimedia files according to frame timing rather than merely
`
`treating them as a byte stream. (See Chen, 3:60-63.) Chen emphasizes this point
`
`repeatedly. (See id., 3:14-23; 8:33-48.)
`
`Frame timing in Chen is achieved by breaking each frame into even smaller
`
`packets, and finely metering the flow of packets so that, by default, each frame is
`
`sent in its corresponding “frame time.” (See id., 9:53-59; 10:10-19.) Chen refers to
`
`this “frame time” as “a key piece of information.” (Id., 8:62-63.) The mechanism
`
`of Chen whereby each frame is sent precisely in its frame time, as detailed at
`
`10:10-19 of Chen, can only work if the unit of data transmission is considerably
`
`smaller than the frame size itself. (See Teruya Decl. ¶ 15.) Doing otherwise would
`
`completely depart from all of the teachings of Chen, fundamentally changing the
`
`operation of Chen. See In re Ratti, 270 F.2d 810, 813 (1959) (finding combination
`
`that changed the “basic principles under which the [prior art] was designed to
`
`operate” insufficient for a case of obviousness); MPEP 2143.01(VI).
`
`
`
`11
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`It would also not be obvious to modify Chen so as to support a “pull”
`
`architecture, as Chen teaches away from a pull mechanism for transmitting the
`
`entire program: “The present invention provides a method for a client machine to
`
`retrieve multimedia data from a server machine with minimum latency and
`
`overhead.” (Chen, 3:41-43.) “In most situations the Tx. Mode is NORMAL. The
`
`NORMAL mode executes frame level pacing and requires minimum overhead,
`
`because limited interaction occurs between the client agent (30) and the server
`
`control (1).” (Id., 10:3-6 (emphasis added).) Contrary to the objectives of minimal
`
`signaling in Chen, the “pull” method of the instant claims requires a great deal of
`
`interaction between the client and the server via multiple requests for sequential
`
`packets to stream an entire program. (See Teruya Decl. ¶¶ 16-17.)
`
`In order to satisfactorily work as a “pull” based server, Chen would have to
`
`generate and serve “chunks” of media that are substantially larger than merely
`
`Chen’s packets – such as chunks that have several frames of media in them.
`
`However, as noted above, Chen actually teaches away from a “pull” mechanism, as
`
`Chen seeks to minimize interaction between the client and the server. (Id. ¶¶ 15-
`
`18.) Further, since Chen already discloses a packetizer for generating packets of
`
`media data from the storage subsystem, there is no teaching or motivation to apply
`
`yet another layer of dicing of the media information obtained from the storage
`
`
`
`12
`
`
`
`subsystem to create yet larger “chunks” simply to support a “pull” architecture.
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`(See Teruya Decl. ¶ 19.)
`
`To the contrary, Chen’s “packetization” is designed to work well for filling
`
`in gaps that develop during “push” delivery. In this context, where packets are
`
`requested on a one-off basis, the smaller the gap to fill the better. But this simply
`
`does not translate into, and to the extent Petitioner would seek to expand the
`
`institution with respect to claims 19, 20, and 23 to go into obviousness – actually
`
`teaches away from – a mechanism for preparing an arbitrarily long stream of
`
`content in the form of temporally contiguous media data elements that are large
`
`enough to overcome associated signaling latencies.
`
`Therefore, for at least the reasons addressed under this heading, claims 19,
`
`20, and 23 are not anticipated by Chen.
`
`B. Willebeek Does Not Cure Fundamental Deficiencies of Chen and
`
`Chen FH With Respect to Claim 21
`
`The combination of Willebeek and Chen to meet the limitations of claim 21
`
`is non-obvious and thus cannot defeat the patentability of claim 21. Petitioner
`
`alleges that it would be obvious to use a circular buffer disclosed in Willebeek in
`
`the context of live broadcasts in place of Chen’s video-on-demand server buffer.
`
`(See Petition 56.) This proposed combination, however, completely ignores Chen’s
`
`scheduler and primary mode of “push” operation, and uses only the lost and
`
`
`
`13
`
`
`
`missing packet mechanisms of Chen. This evisceration of key components of Chen
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`would so alter the principle of operation of Chen as to be non-obvious. See In re
`
`Ratti, 270 F.2d at 813.
`
`The Petition’s discussion of the combination of Chen, Chen FH and
`
`Willebeek is set forth at pages 55-57. It was clearly cut and pasted from a similar
`
`discussion of the same combination in relation to Patent Owner’s ’839 patent in
`
`IPR2016-1658. As such, the argument is directed to going into RUSH mode to
`
`support “push” claims (regarding Chen being “able to rush the first packets to the
`
`user” and then sending at the normal rate) – which is completely irrelevant to
`
`claims 19 and 21, which are directed to a program to prepare streaming media
`
`content for use in a “pull” architecture. The Board should not try to fashion an
`
`invalidity argument that the Petition fails to articulate.
`
`The most that can be said on the basis of the Petition is that claim 21 is
`
`alleged to be obvious simply because the live feed of Willebeek can be supplied to
`
`the system of Chen, which is otherwise alleged to anticipate claim 21’s base claim
`
`(claim 19) by virtue of Chen’s lost packet mechanism. That argument is the most
`
`that can be squeezed out of the Petition with regard to the ground that claim 21 is
`
`obvious over Chen in view of Chen FH and Willebeek.
`
`Claim 21 expressly involves streaming from a live source, making it
`
`inescapable (if it was not already inescapable per claim 19) that continuous
`
`
`
`14
`
`
`
`delivery of the streaming program is required by this claim. (See Teruya Decl. ¶
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`20.)
`
`Thus, in claim 21, the “format” for streaming delivery is expressly for
`
`serving a live stream. The service clearly would be understood by a PHOSITA as
`
`needing to be continuous and uninterrupted in order to be satisfactory. (See id.) Yet
`
`Chen’s streaming units – “packets” of sub-frame size – while suitable for metering
`
`from the server to achieve “frame-level pacing” in a “push” embodiment in
`
`accordance with Chen, are not capable of supporting live streaming playback via a
`
`“pull” mechanism, wherein the server must timely respond to and complete
`
`transmission in response to user requests for media data elements identified by a
`
`serial identifier. Supplying a live feed from Willebeek does not solve this problem.
`
`(See id. ¶ 21.) Indeed, by expressly specifying a live feed, it only makes the
`
`problem worse. (Id.) Chen could not cope with this shortcoming without using
`
`larger chunks for its pull-based delivery mechanism. But larger chunks would
`
`break the frame-level pacing mechanism described in cols. 9-10 of Chen
`
`(beginning at 9:48), because that mechanism can only work on elements smaller
`
`than a frame. (See Teruya Decl. ¶ 21.) The only apparent solution would be for
`
`Chen to use two separate “chunkers” and operating entirely by pull, which would
`
`completely jettison nearly all of Chen. Such “solutions” would not be obvious to a
`
`PHOSITAS – no more obvious than they were to Petitioner’s expert, whose
`
`
`
`15
`
`
`
`declaration neither recognizes nor provides a solution to this problem. (See id. ¶
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`22.)
`
`C. Carmel Does Not Cure Fundamental Deficiencies of Chen and
`
`Chen FH With Respect to Claim 21
`
`A PHOSITA would not seek to graft the live feed of Carmel onto the content
`
`delivery system of Chen as such an individual would recognize that there is little
`
`chance of success for such a combination. (See Teruya Decl. ¶ 23.) The
`
`combination is thus non-obvious and claim 21 is therefore patentable over Chen in
`
`view of Carmel.
`
`Carmel is cited in the Petition only as an alternative source for a live feed for
`
`Chen, which was designed for video-on-demand from prerecorded sources. No
`
`other features of Carmel are cited in the Petition in support of this ground of
`
`institution.
`
`Just as in the case of Chen and Willebeek discussed above, the combination
`
`of Chen with Carmel to address preparation of streaming media for live
`
`transmission via pull suffers from the fundamental deficiency that the elements
`
`provided by Chen are too small to stream by a pull mechanism. (See Teruya Decl.
`
`¶¶ 23-25.)
`
`Additionally, as noted above with respect to Willebeek, serving a live stream
`
`necessarily requires continuous service of the time-sequenced elements comprising
`
`
`
`16
`
`
`
`the live stream. (See id. ¶ 24.) To serve such a live feed, Chen would have to be
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`modified to serve chunks that are significantly larger than its typical packets. Yet,
`
`Chen still needs to support its lost packet mechanism, and as this mechanism
`
`requires relatively smaller packets, Chen would need to chunk the data into two
`
`sizes – one for the missing packets, and a larger size for live streaming
`
`transmissions. (See id.) As with Willebeek, at this point Chen itself, other than its
`
`borrowed and heavily modified packetizer, would play no operational role. A
`
`PHOSITA seeking to use Carmel would likely scrap Chen altogether, rather than
`
`trying to combine the systems, which combination would otherwise require a
`
`major redesign of Chen’s scheduler, packetizer, and pacing command structure.
`
`(See id.) None of this is recognized or addressed in the Petition. In view of the
`
`incompatibilities between the references, the combination cannot be obvious. See
`
`In re Ratti, 270 F.2d at 813; MPEP 2143.01(VI).
`
`
`
`
`
`
`
`17
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`
`
`V. CONCLUSION
`
`Because substantial evidence shows that Chen, Chen FH, Willebeek, and
`
`Carmel, alone or in combination, fail to teach or suggest certain features of claims
`
`19-23, and because the combination of Chen with Willebeek or Carmel is non-
`
`obvious, claims 19-23 are patentable over these references.
`
`
` Dated: May 31, 2017
`
`Respectfully submitted,
`
`
`
`/Ronald Abramson/
`Ronald Abramson
`(Attorney for Patent Owner)
`Reg. No. 34,762
`212-822-0163
`
`
`
`18
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`CERTIFICATION UNDER 37 CFR § 42.24(d)
`
`Under the provisions of 37 CFR § 42.24(d), the undersigned hereby certifies
`
`that the word count for the foregoing Patent Owner Response totals 3,814, which is
`
`less than the 14,000 allowed under 37 CFR §§ 42.24(a)(1)(i); 42.24(b)(2).
`
`
`
`Dated: May 31, 2017
`
`
`
`
`
`
`
`/Ronald Abramson/
`Ronald Abramson
`(Attorney for Patent Owner)
`Reg. No. 34,762
`212-822-0163
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 C.F.R. § 42.6(e), the undersigned hereby certifies that a copy
`
`of the foregoing Patent Owner Response was served on Petitioner by filing through
`
`the PTAB E2E System and via email to dyohannan@kelleydrye.com,
`
`DCpatentdocket@kelleydrye.com, bjacob@kelleydrye.com, and
`
`syovits@kelleydrye.com, as authorized in Petitioner’s amended mandatory notices.
`
`
`
`Dated: May 31, 2017
`
`
`
`/Ronald Abramson/
`Ronald Abramson
`(Attorney for Patent Owner)
`Reg. No. 34,762
`212-822-0163
`
`
`
`
`
`2
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
