`
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`TWITTER, INC.,
`Petitioner,
`
`v.
`
`VIDSTREAM LLC,
`Patent Owner.
`_________________
`
`Case IPR2017-01133
`Patent 8,601,506
`_________________
`
`PETITIONER’S REPLY TO
`PATENT OWNER’S RESPONSE TO PETITION
`
`
`
`
`
`
`TABLE OF CONTENTS
`
`IPR2017-01133
`Patent 8,601,506
`
`Page(s)
`
`EXHIBIT LIST ........................................................................................................ iv
`
`I.
`
`II.
`
`INTRODUCTION ........................................................................................... 1
`
`PO RELIES ON AN UNREASONABLE CHARACTERIZATION OF
`HOW A POSITA WOULD UNDERSTAND LAHTI’S DISCLOSURE ...... 1
`
`A.
`
`PO’s Argument Is Inconsistent With Lahti’s Explicit Disclosure ....... 2
`
`1. MobiCon Is A Robust Video Production Application ................ 2
`
`2.
`
`PO’s Native-Capability-Only Argument Is
`Inconsistent With The MobiCon Architecture ........................... 5
`
`PO Mischaracterizes The Pertinent State Of The Art ........................... 8
`
`The Specification’s Disclosure Regarding
`Server-Provided Instructions That Cause Video Capture ..................12
`
`B.
`
`C.
`
`III. A POSITA WOULD HAVE BEEN
`MOTIVATED TO INCORPORATE CONWAY’S
`AND CURRENT TV’S VIDEO LENGTH TEACHINGS ...........................14
`
`A.
`
`B.
`
`C.
`
`The Patent Specification Suggests Obviousness .................................14
`
`Lahti Does Not Teach Away From Limiting Video Length ...............15
`
`Conway Teaches Constraining Video Length ....................................18
`
`1.
`
`2.
`
`Because Petitioner Relies Only On
`Conway’s Disclosure Of A Limit On Video
`Clip Length, PO’s Reliance On Conway’s Use
`Of A Media Player To Create Clips Is Irrelevant .....................19
`
`Conway Teaches Restricting Video Length,
`Irrespective Of The Source Of The Media Content ..................20
`
`D.
`
`Current TV Teaches Restricting Video Length ..................................21
`
`Page i
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`E.
`
`
`A POSITA Would Have Been Motivated To
`Incorporate Video Length Constraints Into Lahti And Novak ...........22
`
`1.
`
`2.
`
`3.
`
`The Law Of Obviousness ..........................................................22
`
`Incorporating Conway’s Video Clip Length Constraint
`Would Have Improved Performance Of Lahti And Novak ......23
`
`Current TV Provided A Monetary Motivation
`To Incorporate Video Length Constraints Into Lahti
`And Novak, And It Would Have Improved Performance ........24
`
`IV. CONCLUSION ..............................................................................................25
`
`CERTIFICATE OF COMPLIANCE ......................................................................27
`
`
`
`
`
`
`
`Page ii
`
`
`
`
`TABLE OF AUTHORITIES
`
`IPR2017-01133
`Patent 8,601,506
`
`Page(s)
`
`Cases
`
`Application of Fox,
`471 F.2d 1405 (C.C.P.A. 1973) ............................................................................15
`
`ClassCo, Inc. v. Apple, Inc.,
`838 F.3d 1214 (Fed. Cir. 2016) ............................................................................22
`
`In re Epstein,
`32 F.3d 1559 (Fed. Cir. 1994) ..............................................................................15
`
`In re Keller,
`642 F.2d 413 (C.C.P.A. 1981) ..............................................................................23
`
`In re Mouttet,
`686 F.3d 1322 (Fed. Cir. 2012) ............................................................................18
`
`KSR Int’l Co. v. Teleflex, Inc.,
`550 U.S. 398 (2017) ...................................................................................... 22, 25
`
`Meiresonne v. Google, Inc.,
`849 F.3d 1379 (Fed. Cir. 2017) ............................................................................16
`
`Nidec Motor Corp. v. Zhongshan Borad Ocean Motor Co. Ltd.,
`868 F.3d 1013 (Fed. Cir. 2017) ............................................................................17
`
`Unwired Planet, LLC v. Google Inc.,
`841 F.3d 995 (Fed. Cir. 2016) ................................................................................ 8
`
`Rules
`
`Fed. R. Evid. 801-807 ................................................................................................ 8
`
`
`
`
`
`
`
`Page iii
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`EXHIBIT LIST
`
`LIST OF PREVIOUSLY FILED EXHIBITS
`
`Exhibits 1001-1017: Filed and served March 24, 2017 with Twitter’s Petition for
`
`Inter Partes Review of U.S. Patent No. 8,601,506.
`
`Exhibit 1018: Filed and served October 18, 2017 with Petitioner’s Unopposed
`
`Motion for Pro Hac Vice of Robert T. Cruzen.
`
`Exhibit 1019: Filed and served February 2, 2018 with Petitioner’s Updated Exhibit
`
`List.
`
`Exhibit 1020-1021: Filed and served February 20, 2018 with Petitioner’s Updated
`
`Exhibit List.
`
`Exhibit 1022: Filed and served February 23, 2018 with Petitioner’s Updated Exhibit
`
`List.
`
`Exhibit 1023-1024: Filed and served March 6, 2018 with Petitioner’s Updated
`
`Exhibit List.
`
`Exhibit 1025: Filed and served March 14, 2018 with Petitioner’s Updated Exhibit
`
`List.
`
`Exhibit 1026: Filed and served March 29, 2018 with Petitioner’s Updated Exhibit
`
`List.
`
`Exhibit 1027: Filed and served April 5, 2018 with Petitioner’s Updated Exhibit List.
`
`Page iv
`
`
`
`
`Exhibit 1028-1029: Filed and served April 11, 2018 with Petitioner’s Updated
`
`IPR2017-01133
`Patent 8,601,506
`
`Exhibit List.
`
`Exhibit 1030: Filed and served May 3, 2018 with Petitioner’s Updated Exhibit List.
`
`Exhibits 1031-1032: Intentionally not used.
`
`NEW EXHIBIT LIST:
`
`No. Description
`
`1033 Fonearena.com Nokia E50 specifications, October 21, 2006
`
`1034 CNET.com document entitled “Nokia E50-1 - smartphone - GSM
`Series Specs” - (Identified at Dr. Olivier’s Deposition on July 24,
`2018. Not Filed)
`
`1035 Mobile88.com Nokia N73 Specification - (Identified at Dr. Olivier’s
`Deposition on July 24, 2018. Not Filed)
`
`1036 Article entitled “Samsung Starts Selling World’s First 10 Megapixel
`Camera Phone”, October 10, 2006
`
`1037 Letsgodigital.com article referencing Samsung SCH-V7770, March
`10, 2008
`
`1038 Cypress Semiconductor Corporation Advance Information for
`CYIWCDC1300AA - (Identified at Dr. Olivier’s Deposition on July
`24, 2018. Not Filed)
`
`1039
`
`“Multimedia on Symbian OS, Inside the Convergence Device” -
`(Identified at Dr. Olivier’s Deposition on July 24, 2018. Not Filed)
`
`1040 Document from Symbian Developer Library entitled “Class
`TCameraInfo” - (Identified at Dr. Olivier’s Deposition on July 24,
`2018. Not Filed)
`
`Page v
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`No. Description
`
`
`
`1041 Document entitled “Class·CCamera” from Symbian Developer
`Library (2007) - (Identified at Dr. Olivier’s Deposition on July 24,
`2018. Not Filed)
`
`1042 Document entitled “Class·CCamera” from Symbian Developer
`Library (2006) - (Identified at Dr. Olivier’s Deposition on July 24,
`2018. Not Filed)
`
`1043 Document entitled “Class·CCamera” from Symbian Developer
`Network, S60 SDKs”, February 9, 2006
`
`1044 Document entitled “Symbian Phones”, December 20, 2006
`
`1045 Article from Wire.com entitled “By Open Sourcing Symbian, Nokia
`Kicks off the Mobile Age”, June 24, 2008
`
`1046 Article from Mobile-Review.com·entitled “The company of Sharp -
`models of 2005 and strategy” - (Identified at Dr. Olivier’s
`Deposition on July 24, 2018. Not Filed)
`
`1047 Symbian OS SDK v8.1 from·Symbian Developer Library, February
`8, 2008
`
`1048 Document entitled “CCamera in Multimedia ECam” Symbian OS
`SDK V8.1 from Symbian Developer Library, September 17, 2006
`
`1049 Article from Samsung Mobile News entitled “SAMSUNG Launches
`the World’s First 10 Megapixel Camera Phone”, October 10, 2006
`
`1050 Article entitled “Samsung SCH-B600 10 Megapixel Camera Phone,
`October 10, 2006
`
`1051 Deposition Transcript of James Olivier, Ph.D., July 24, 2018
`
`1052 Supplemental Declaration of Henry Houh
`
`
`
`Page vi
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`I.
`
`INTRODUCTION
`
`Patent Owner’s (“PO”) Response (Paper 47 (“Response”)) fails to refute the
`
`Petition’s showing that the Challenged Claims are unpatentable as obvious over the
`
`prior art. In particular, PO relies on an unreasonable characterization of the teachings
`
`of the Petition’s primary prior art, Lahti, by ignoring the express language of the
`
`reference itself, the state of the pertinent art, and by misapplying the law of
`
`obviousness.
`
`II.
`
`PO RELIES ON AN UNREASONABLE CHARACTERIZATION OF
`HOW A POSITA WOULD UNDERSTAND LAHTI’S DISCLOSURE
`
`Each Challenged Claim requires server-provided instructions that “cause the
`
`video data to be captured in accordance with predetermined constraints …”1 See Ex.
`
`1001, independent claims 1, 23, 26. PO’s argument that Lahti does not disclose this
`
`limitation is based on a mischaracterization of how a person having ordinary skill in
`
`the art (“POSITA”) would understand the teachings of Lahti. PO’s argument is
`
`incompatible with the state of the art to the extent PO contends (1) that mobile
`
`phones possessed only a single set of native recording parameters at the time of
`
`Lahti’s publication, and (2) setting constraints for mobile phones using instructions
`
`
`1 PO raises the construction of “predetermined constraints” proposed by
`Petitioner. Response at 6-7. However, Petitioner does not contend for purposes of
`the petition that the term requires that all examples of such constraints listed in
`Petitioner’s proposed construction of the term be present in a system in order for
`the claim limitation to be met.
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 1
`
`
`
`
`provided by a server presented such a significant technological obstacle that no
`
`reasonable developer would undertake it. Neither contention is true. See infra at 8-
`
`IPR2017-01133
`Patent 8,601,506
`
`12.
`
`A.
`
`PO’s Argument Is Inconsistent
`With Lahti’s Explicit Disclosure
`
`There is no dispute that the MobiCon application satisfies the “instructions”
`
`limitation of the Challenged Claims. However, PO contends that a POSITA would
`
`understand Lahti to disclose that any constraints used by MobiCon during video
`
`capture would have been provided by the device’s native capabilities, and not by the
`
`server system from where MobiCon was downloaded. Response at 11-12. However,
`
`PO’s native-capability-only characterization ignores the text of Lahti, ignores the
`
`purpose of MobiCon, and understates the full teachings of Lahti.
`
`1. MobiCon Is A Robust Video Production Application
`
`PO suggests that a POSITA would narrowly interpret MobiCon as merely
`
`passively implementing native capabilities of three 2006-era Nokia devices. Id. But
`
`there is simply no credible support for such a characterization, as it ignores much of
`
`Lahti’s explicit text describing MobiCon as a robust, video production tool:
`
`We present a video management system comprising a
`
`video server and a mobile camera-phone application called
`
`MobiCon, which allows users to capture videos, annotate
`
`them with metadata, specific digital rights management
`
`(DRM) settings, upload the videos over the cellular
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 2
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`
`network, and share them with others. … Our work takes
`
`steps forward in advancing the mobile camera-phone from
`
`a video playback device to a video production tool.
`
`Ex. 1006 at 1.
`
`Any MCP application, such as MobiCon, should be robust
`
`and rich in functionality …
`
`Video recording,
`
`the
`
`first
`
`function,
`
`is
`
`relatively
`
`straightforward to implement with vendor provided SDKs.
`
`However, the application should be robust during this
`
`phase and capable of handling critical events (including
`
`incoming phone calls and text messages).
`
`Id. at 3.
`
`In describing the system architecture, Lahti explicitly states that MobiCon’s
`
`“UIManager is a controller component,” and further that it “coordinates the video
`
`capture using the mobile phone’s camera …” Id. at 5. Lahti goes on to explain that
`
`when capturing new video, “MobiCon’s main screen is displayed” and a “new video
`
`clip is captured in Capture Screen using Mobile Media API and it is recorded
`
`according to 3GPP specification using AMR coding for audio and H.263 at 176x144
`
`pixels size at 15 frames per second for video.” Id. at 6. This is all handled by
`
`MobiCon’s UIManager which is a “controller component.” At his deposition, PO’s
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 3
`
`
`
`
`expert, Dr. Olivier, conceded that this suggests that MobiCon’s UIManager
`
`controlled at least some aspects of the video capture process:
`
`IPR2017-01133
`Patent 8,601,506
`
`A. The -- the typical usage of a UIManager, user interface
`
`manager, is it’s controlling – it’s receiving what’s -- and
`
`maintaining what the user is inputting and outputting, and
`
`then it hands that information off to something else in
`
`order to do some other functionality.
`
`Q. So there’s something else that hands that information
`
`off to. Does it necessarily control every aspect of that
`
`something else?
`
`A. Not necessarily.
`
`Ex. 1051, 136:7-22.
`
`Dr. Olivier’s testimony that the normal usage of “controller” suggests that it
`
`controls the features with which it interacts, but “not necessarily” every feature, is
`
`consistent with Dr. Houh’s interpretation that MobiCon captures video according to
`
`server-provided constraints. Paper 1 (“Petition”) at 27; Ex. 1003, ¶¶ 102-106; Ex.
`
`1052, ¶¶ 13-20. Here, Lahti identifies the features that MobiCon controls, and they
`
`are at the very least the particular recording parameters expressly delineated in the
`
`reference. Ex. 1006 at 6.
`
`Lahti concludes that “there is currently no similar mobile application that
`
`combines all video management features, i.e., video capturing, annotation using
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 4
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`different context sources, sharing and storing videos for searching, into one [6, 13].”
`
`Id. at 10. The only rational reading of Lahti is that MobiCon was doing much more
`
`than merely passively engaging with the video capture process. To the contrary, the
`
`explicit disclosures set forth above are entirely consistent with Dr. Houh’s opinion
`
`that a POSITA would understand that the MobiCon instructions, which are
`
`downloaded from the server, include the resolution and frame rate parameters, and
`
`control the video capture process in accordance with those instructions. Petition at
`
`27; Ex. 1003, ¶¶ 102-106; Ex. 1052, ¶¶ 13-20.
`
`2.
`
`PO’s Native-Capability-Only Argument Is
`Inconsistent With The MobiCon Architecture
`
`Lahti states that MobiCon interacts with a mobile phone through an
`
`application interface to effect video capture, including immediately before noting
`
`that MobiCon allows videos to be captured with specified parameters, including a
`
`frame rate of 15 frames per second (“fps”). Ex. 1006 at 6. Lahti emphasizes that
`
`enabling MobiCon to control the video recording capabilities of a mobile phone, and
`
`to foster the goals of the application to minimize network traffic, conserve battery
`
`power and minimize use of the CPU and memory, presents difficulties because of
`
`the varying characteristics of mobile phones features and operating systems:
`
`Moreover, application developers must pay attention to
`
`the way resources are used: network traffic should be
`
`minimized, battery power should be conserved when
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 5
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`
`possible, and CPU and memory ought to be utilized with
`
`frugality. These restrictions come on top of the classic
`
`mobile phone application development nightmares (device
`
`incompatibilities,
`
`network
`
`application
`
`debugging,
`
`immature SDKs, and different operating system versions
`
`with undocumented bugs) making the development of an
`
`application like MobiCon challenging.
`
`Id. at 3 (emphasis added).
`
`PO argues that this passage means that MobiCon’s developers simply chose
`
`not to engage in these challenges at all insofar as the application relates to the capture
`
`of videos. Response at 18. That interpretation is nonsensical. Ex. 1052, ¶¶ 18-20.
`
`Lahti is explicit that MobiCon does control video recording on various types of
`
`mobile phones, and does so in conjunction with vendor provided software
`
`development kits.
`
`Video recording,
`
`the
`
`first
`
`function,
`
`is
`
`relatively
`
`straightforward to implement with vendor provided SDKs.
`
`Ex. 1006 at 3. If MobiCon did not affect the manner in which video was recorded,
`
`and instead relied solely on each device’s native recording capabilities, there would
`
`be no reason for Lahti to disclose the identified frame rate, let alone disclose using
`
`SDKs to implement video recording. See Ex. 2008, 61:25-63.8.
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 6
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`
`PO also argues that because Lahti discloses the ability to upload natively
`
`captured videos, it would be pointless to provide parameters for video capture.
`
`Response at 11. But this makes no sense, and is contrary to the understanding of a
`
`POSITA. Ex. 1052, ¶¶ 7-20.
`
`As detailed below, a POSITA would understand that devices in the pertinent
`
`timeframe were capable of recording at multiple resolutions and frame rates, and
`
`would have been very familiar with mobile application development tools, such as
`
`SDKs and APIs that accompany mobile devices’ operating systems, and would have
`
`known that such tools could be programmed to specify certain parameters, including
`
`the resolution and frame rate at which video recording should be made. See infra at
`
`8-12.
`
`PO’s argument also is contrary to the ’506 Patent specification, which
`
`recognizes that the downloaded instructions “interface[] with native device
`
`recording capabilities.” Ex. 1001, 6:5-8; claim 24. The fact that MobiCon would
`
`contribute to the efficient transcoding of videos captured using the described
`
`controller—likely most of the videos uploaded to servers—would still serve the
`
`purposes of the system, even if a few other videos captured in other ways could also
`
`be uploaded to servers.
`
`PO’s argument is essentially that if the predetermined constraint limitation is
`
`not practiced 100% of the time when capturing videos that are later uploaded to the
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 7
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`servers described by Lahti, it is not taught by Lahti for purposes of unpatentability.
`
`But that is not the law. See Unwired Planet, LLC v. Google Inc., 841 F.3d 995, 1001
`
`(Fed. Cir. 2016) (aff’g Board’s decision of unpatentability noting “[i]t is enough that
`
`the combination would sometimes perform all the method steps ....”).
`
`B.
`
`PO Mischaracterizes The Pertinent State Of The Art
`
`As noted above, PO relies heavily on certain alleged characteristics of three
`
`models of Nokia devices from the 2006 timeframe. Response at 14-21. PO’s reliance
`
`on these documents is a red herring for several reasons.
`
`
`
`First, PO is cherry picking a few Nokia models. The only justification appears
`
`to be that one of the Nokia models mentioned by PO is the device identified in Lahti
`
`near the end of the article (page 8) as being used in the Field Trial Evaluation of
`
`MobiCon. But Lahti’s mention of the Nokia 6630 is trivial; it follows long after
`
`thoroughly describing MobiCon’s functionality and architecture. Lahti had no
`
`reason to mention any particular device in the substantive portions of the paper. The
`
`Nokia 6630 just happened to be the device chosen for the evaluation.
`
`Second, PO’s purported “evidence” is not helpful, and is hearsay.
`
`Specifically, PO offers Exhibits 2003-2007 for the truth of the matter asserted,
`
`namely that certain devices had certain characteristics. This is hearsay and should
`
`not be considered. Fed. R. Evid. 801-807.
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 8
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`
`Even if the Board considers these exhibits, they in no way limit or change the
`
`teachings of Lahti in any way. For example, PO concedes that the Nokia 6630 can
`
`record video at two distinct resolutions. Response at 19. PO also relies on the Nokia
`
`E50 as recording at a single resolution. Id. at 17. However, other documents, not
`
`mentioned by PO, show that the E50 was capable of recording at multiple
`
`resolutions. Ex. 10332. That a phone supports multiple resolutions is consistent with
`
`Dr. Houh’s explanation that Lahti’s MobiCon (an application comprised of
`
`“instructions” provided to a mobile device by the server) provides parameters to be
`
`utilized by the device. See Ex. 1052, ¶¶ 13-15. If a device presented two choices of
`
`resolution parameters, and MobiCon can select one of them, the claim limitation is
`
`satisfied because MobiCon—the “instructions” provided by the server—dictates the
`
`capture parameter used to capture video.
`
`PO also relies on a review of the Nokia 6270. Response at 17. The review
`
`states without citation that “you can’t set another resolution” on the phone. Ex. 2003
`
`at 29. But a random review site purporting to identify features of a particular phone
`
`is irrelevant to the question of whether a POSITA would understand that mobile
`
`phone settings could be modified using programming tools.
`
`
`2 New Exhibits 1033, 1043, 1044, 1047, 1048, and 1050 were obtained from
`the Internet Archive. Ex. 1052, ¶ 2. An affidavit in the form of Ex. 1016 will be
`served upon receipt (request originally made on July 20, 2018).
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 9
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`
`In reality, a POSITA would understand Lahti to teach that changes are made
`
`to mobile phone settings using Software Developer Kits, which are tools used by the
`
`paper’s authors, stating that “[v]ideo recording … is relatively straightforward to
`
`implement with vendor provided SDKs.” Ex. 1006 at 3. Dr. Houh elaborated at his
`
`deposition how Lahti discloses that the MobiCon application specified parameters,
`
`including frame rate, for video capture:
`
`But what I’m saying is that based on the teachings of the
`
`Lahti patent, it’s teaching that you can use it on a wide
`
`variety of vendor phones; that it’s – that’s what the
`
`MobiCon is for, and that you can use the SDKs. And, as I
`
`said generally speaking, SDKs are designed to allow
`
`application programmers to do things; not disallow them
`
`typically in terms of accessing specific functions of the
`
`underlying system, and that -- and that this particular
`
`walk-through is teaching that there’s a recording at a very
`
`specific pixel size and a very specific frame rate which it
`
`says and that the reference is teaching that the MobiCon
`
`app provides parameters by which the mobile device on
`
`which the application is executing captures video data and
`
`those parameters expressly include a frame rate.
`
`Ex. 2008, 91:3-20; see also Id., 63:10-68:2, 75:10-76:4, 83:7-86:11.
`
`Third, PO’s argument is contrary to how a POSITA would understand the
`
`pertinent state of the art, including how POSITAs would interpret Lahti. A POSITA
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 10
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`would have understood Lahti to be providing the video capture constraints from the
`
`server to the client via MobiCon, to cause video capture in accordance with the
`
`constraints. Ex. 1003, ¶¶ 102-106. PO’s argument to the contrary is based on
`
`unconfirmed capabilities of three Nokia devices from the 2006 timeframe. PO not
`
`only ignores other Nokia devices, but ignores other device manufacturers, and also
`
`ignores mobile application tools such as operating systems, APIs, and SDKs of
`
`which POSITAs would have been familiar. Ex. 1052, ¶¶ 5-16. PO also ignores any
`
`advancements made in the state of the art after Lahti published and before the date
`
`of the invention of the Challenged Claims. Id., ¶¶ 9-10.
`
`Despite being aware of other manufacturers and devices, Dr. Olivier
`
`remarkably limited his analysis to three Nokia devices from the 2004-2006
`
`timeframe. Ex. 1051, 57:20-58:16, 86:13-21. Other devices, such as two Samsung
`
`devices—from the same era as the Nokia devices relied on by PO—could record
`
`video at frame rates that exceeded 15 fps. For example, the Samsung SCH-V770 and
`
`the Samsung SCH-B600 each could record video at 15-30 fps. Ex. 1036 at 2; Ex.
`
`1037 at 1; Ex. 1049 at 1; Ex. 1050 at 1. By specifying that a device records at a
`
`particular frame rate, e.g., 15 fps, MobiCon would be providing instructions
`
`dictating a predetermined constraint.
`
`PO and Dr. Olivier also ignored skilled artisans’ familiarity with state of the
`
`art mobile application tools and operating systems. For example, the Symbian OS
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 11
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`was one of the most popular operating systems for mobile phones during the relevant
`
`timeframe. Ex. 1052, ¶ 7. Indeed, Nokia models, as well as other leading devices ran
`
`on the Symbian OS. Ex. 1044. By 2006, the Symbian OS provided mobile phones
`
`with APIs that supported a variety of multimedia functions, including video capture
`
`at varying resolutions and frame rates. Id., ¶ 14 (Dr. Houh describing
`
`EnumerateVideoFrameRates(),
`
`EnumerateVideoFrameSizes(),
`
`PrepareVideoCaptureL(), and StartVideoCapture() API functions); see also Ex.
`
`1048 at 15-19.
`
`C. The Specification’s Disclosure
`Regarding Server-Provided
`Instructions That Cause Video Capture
`
`PO argues that Lahti is silent regarding the extent to which MobiCon “impacts
`
`video-capture parameters,” or “governs the recited video parameters.” Response at
`
`9. However, Lahti specifies parameters that are employed (frame rate, resolution,
`
`video/audio encoding) and discloses as much detail regarding server-provided
`
`constraints used to cause video capture as does the ’506 Patent.
`
`Neither the Challenged Claims, nor the ’506 Patent specification recites that
`
`the constraints must “impact” or “govern” video capture in a manner beyond what
`
`Lahti expressly discloses. Instead, the specification recites the following:
`
`The operations are performed using
`
`instructions
`
`transmitted to the client computing device downloaded
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 12
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`
`from a web server and installed on the client device, and
`
`capturing high definition video data using the digital
`
`camera includes interfacing with native device recording
`
`capabilities. The predetermined constraints are adapted to
`
`enable a transcoding server to perform automated
`
`transcoding of the high definition video data into a
`
`plurality of video file formats.
`
`Ex. 1001, 6:4-11.
`
`[b]y
`
`formatting
`
`the video content according
`
`to
`
`predetermined constraints, the video content can be
`
`transcoded …
`
`Id., 9:21-23.
`
`The native recording capabilities of the user computing
`
`device 120 can be accessed to receive captured video and
`
`audio data through an API on the computing device 120.
`
`Id., 12:30-32.
`
`The mobile application can be opened and the user can log
`
`into the mobile application using pre-defined credentials.
`
`A mobile recording user interface (MRUI) is launched
`
`(502) by, for example, selecting a video capture button on
`
`a bottom-right-hand corner of the user interface (see FIG.
`
`19). A “Record New Video” option (see FIG. 19) can be
`
`selected (504), and the user can be presented with
`
`recording options.
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 13
`
`
`
`
`Ex. 1001, 24:2-8.
`
`Lahti provides a comparable level of detail by disclosing:
`
`IPR2017-01133
`Patent 8,601,506
`
` a user downloading and installing the MobiCon application;
`
` a user logging in using credentials;
`
` launching a recording interface, including a video capture button;
`
` capturing video using Mobile Media API; and
`
` recording the video in a format that can be transcoded.
`
`Ex. 1006 at 6-7; Ex. 1051, 75:20-78:18.
`
`III. A POSITA WOULD HAVE BEEN
`MOTIVATED TO INCORPORATE CONWAY’S
`AND CURRENT TV’S VIDEO LENGTH TEACHINGS
`
`Other than the server-provided constraints limitation discussed above, the
`
`video length limitation is the only other limitation PO argues as a distinguishing
`
`feature from the prior art. PO, however, misunderstands the teachings of the prior
`
`art, and also misunderstands the law.
`
`A. The Patent Specification Suggests Obviousness
`
`Each Challenged Claim requires that a “video length” be one of the server-
`
`provided constraints used during video capture. The ’506 Patent Applicants do not
`
`claim to have invented constraining the length of videos, nor do they purport to have
`
`invented some special technique for doing so. Instead, the ’506 Patent specification
`
`is written as if constraining video length was already known to skilled artisans. It
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 14
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`says nothing about how to enable video length restrictions. See Ex. 1001, 11:31-53.
`
`Instead, it merely assumes that “the duration settings control” is available, discusses
`
`settings options and why an implementer may want to restrict the length of videos,
`
`but fails to describe how to create it or how it works. Id. at 19:32-64.
`
`Such lack of detail regarding the video length limitation confirms that it was
`
`a matter of common knowledge at the time the patent was filed. See, e.g., Ex. 1052,
`
`¶ 24 (Dr. Houh describing YouTube video length); see also Application of Fox, 471
`
`F.2d 1405, 1407 (C.C.P.A. 1973) (finding claimed method obvious and stating fact
`
`that method was “admittedly old . . . in part is deducible from the fact that it assumes
`
`anyone desiring to carry out the process would know of the equipment and
`
`techniques to be used, none being specifically described.”); cf. In re Epstein, 32 F.3d
`
`1559, 1568 (Fed. Cir. 1994) (citing Fox with approval).
`
`B.
`
`Lahti Does Not Teach Away From Limiting Video Length
`
`Lahti discloses a server system providing instructions that cause a client
`
`computing device to capture video data in accordance with predetermined
`
`constraints. Ex. 1003, ¶¶ 102-106; Petition at 27. Lahti does not, however, explicitly
`
`disclose video length as one of the constraints. Instead, Petitioner relies on the
`
`teachings of Conway for Ground 1, and Current TV for Ground 2, as disclosing the
`
`video length constraint. Petition at 28, 29, 65.
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 15
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`
`PO mistakenly argues that Lahti “teaches away from limiting video length,”
`
`and would not have been combined with video length teachings. Response at 22-28.
`
`PO relies on Lahti’s exemplary disclosure of end users capturing and distributing
`
`home videos and a server storage system for such videos. Id. However, Lahti
`
`explicitly states that it is not limited to “personal home video domain” and can be
`
`used “for different video management applications by using some of the generic
`
`components and adding domain-specific ones.” Ex. 1006 at 4.
`
`Lahti in no way suggests to a POSITA that a system using MobiCon and its
`
`associated server, Candela, would be limited to only the functionality expressed in
`
`Lahti. Although Lahti identifies problems and difficulties in prior mobile video
`
`management systems, Lahti certainly does not discourage, criticize, or otherwise
`
`teach away from incorporating a video length constraint into MobiCon. See
`
`Meiresonne v. Google, Inc., 849 F.3d 1379, 1382 (Fed. Cir. 2017) (“A reference that
`
`‘merely expresses a general preference for an alternative invention but does not
`
`criticize, discredit, or otherwise discourage investigation into’ the claimed invention
`
`does not teach away.” (quoting Galderma Labs. L.P. v. Tolmar, Inc., 737 F.3d 731,
`
`738 (Fed. Cir. 2013).)
`
`PO has not identified a single passage in Lahti that criticizes, discredits, or
`
`otherwise discourages incorporating a video clip length constraint into MobiCon.
`
`Incorporating a “video length” constraint into MobiCon would have been an obvious
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`Page 16
`
`
`
`IPR2017-01133
`Patent 8,601,506
`
`
`implementation detail that is completely consistent with the idea of allowing users
`
`to capture and share videos. See Ex. 1052, ¶¶ 2