`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________________________
`
`
`TWITTER, INC.
`
`
`
`Petitioner
`
`
`v.
`
`
`VIDSTREAM, LLC
`
`Patent Owner
`
`_____________________________
`
`
`Case IPR2017-01133
`U.S. Patent No. 8,601,506
`(Claims 1, 4-8, 11, 13-15, 23-26, and 29-30)
`_____________________________
`
`
`VIDSTREAM LLC’s PATENT OWNER’S RESPONSE
`
`
`73074720.2
`
`
`
`IPR2017-00133
`U.S. Patent No. 8,601,506
`
`TABLE OF CONTENTS
`
`C.
`
`INTRODUCTION ........................................................................................... 1
`I.
`THE ’506 PATENT ......................................................................................... 1
`II.
`III. LEVEL OF ORDINARY SKILL IN THE ART ............................................. 4
`IV. CLAIM CONSTRUCTION ............................................................................ 5
`A.
`“predetermined constraints” (claims 1, 2, 6, 7, 13, 23, 2) ..................... 6
`B.
`Other claim terms .................................................................................. 8
`V. GROUNDS 1-2: LAHTI DOES NOT DISCLOSE A SERVER
`PROVIDING INSTRUCTIONS TO A CLIENT COMPUTING DEVICE
`TO CAUSE VIDEO DATA TO BE CAPTURED IN ACCORDANCE
`WITH PREDETERMINED CONSTRAINT(S) DEFINED BY THE
`INSTRUCTIONS ............................................................................................ 8
`A.
`Lahti does not say MobiCon impacts video-capture parameters .......... 9
`B.
`Lahti discloses only one example of MobiCon functionality from
`the user perspective of typical usage scenarios ................................... 12
`Dr. Houh’s opinion relies on an unsupported assumption about the
`native capabilities of camera phones available in 2006 ...................... 13
`D. Other publications suggest that Lahti’s recited video-capture
`parameters were standard for camera phones and therefore not
`impacted by MobiCon ......................................................................... 15
`VI. GROUNDS 1-2: LAHTI TEACHES AWAY FROM LIMITING VIDEO
`LENGTH ....................................................................................................... 22
`A. Artificially limiting video length is contrary to Lahti’s goal of
`giving the end user control of their videos .......................................... 23
`Lahti already addresses the problems that Dr. Houh contends
`warrant artificially limiting the length of captured video ................... 25
`VII. GROUNDS 1-2: CONWAY DOES NOT AND CANNOT SUPPLY
`THE ELEMENTS MISSING FROM LAHTI ............................................... 28
`A.
`Conway discloses a viewer viewing streaming media on a media
`player and optionally using the media player to generate shortened
`media clips ........................................................................................... 29
`Applying Conway’s clipping approach to Lahti does not result in
`the claimed invention of the ’565 Patent ............................................. 33
`
`B.
`
`B.
`
`73074720.2
`
`
`
`C.
`
`B.
`
`Case IPR2017-01133
`Patent 8,601,506
`Petitioner’s reasons for combining Lahti and Conway are premised
`on a misunderstanding of Lahti and how it would be combined
`with Conway ........................................................................................ 36
`Conway never discloses shortening personal video ............................ 38
`D.
`VIII. GROUND 2: CURRENT TV DOES NOT DISCLOSE ANY LIMIT ON
`VIDEO LENGTH .......................................................................................... 41
`A. Dr. Houh does not identify any predetermined video length
`constraint defined at a server and applied when capturing video ....... 41
`Dr. Houh’s reliance on Current TV conflicts with his own claim
`construction ......................................................................................... 45
`IX. GROUND 1-2: NOVAK SIMILARLY FAILS TO DISCLOSE
`LIMITING VIDEO LENGTH DURING CAPTURE ................................... 46
`A.
`The Petition and Dr. Houh do not contend Novak teaches capturing
`video according to a predetermined length constraint ........................ 46
`Novak teaches away from limiting video length................................. 47
`B.
`X. GROUND 1: LAHTI COMBINED WITH CONWAY AND NOVAK ....... 49
`A.
`The combination of references does not teach capturing video in
`accordance with predetermined constraints ........................................ 49
`The combination of references does not teach capturing video in
`accordance with a predetermined video length constraint .................. 51
`XI. GROUND 2: LAHTI IN VIEW OF NOVAK AND “CURRENT TV
`MOBILE” AND “CURRENT TV FAQ” ...................................................... 53
`A.
`Current TV does not teach capturing in accordance with
`predetermined constraints ................................................................... 53
`Current TV does not disclose a predetermined video length defined
`by instructions ..................................................................................... 54
`XII. CONCLUSION .............................................................................................. 55
`
`B.
`
`B.
`
`73074720.2
`
`- 3 -
`
`
`
`IPR2017-00133
`U.S. Patent No. 8,601,506
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`In re Cuozzo Speed Techs.,
`793 F.3d 1268 (Fed. Cir. 2015) ............................................................................ 5
`
`Ferguson Beauregard/Logic Controls, Div. of Dover Res., Inc. v.
`Mega Sys., LLC,
`350 F.3d 1327 (Fed. Cir. 2003) ............................................................................ 6
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) (en banc) ............................................................ 5
`Straight Path IP Grp., Inc. v. Sipnet EU S.R.O.,
`806 F.3d 1356 (Fed. Cir. 2015) ............................................................................ 6
`TriVascular, Inc. v. Samuels,
`812 F.3d 1056 (Fed. Cir. 2016) ........................................................................ 5, 6
`Other Authorities
`83 FR 21221 ............................................................................................................... 5
`
`
`73074720.2
`
`
`
`IPR2017-00133
`U.S. Patent No. 8,601,506
`
`TABLE OF EXHIBITS
`
`Description
`No.
`2001 Official Notice of Bankruptcy Case Filing, U.S. Bankruptcy Court for the
`Western District of Oklahoma, Case No., 17-14849 (filed November 30,
`2017)
`2002 Declaration of James Olivier, Ph.D.
`2003 Webpage entitled “Review GSM phone Nokia 6270” that was archived by
`the Wayback Machine at web.archive.org on February 5, 2006
`2004 Webpage entitled “Nokia E50 Hands-on Preview” that was archived by
`the Wayback Machine at web.archive.org on May 30, 2006
`2005 Nokia webpage listing specifications of the Nokia 6630 that was archived
`by the Wayback Machine at web.archive.org on December 29, 2004
`2006 Webpage entitled “Nokia 6630 (Nokia Charlie) Detailed Tech Specs”
`2007
`CNET webpage entitled “Nokia 6630 – smartphone – GSM / UMTS
`Series Specs”
`Transcript of June 20, 2018 Deposition of Henry Houh, Ph.D.
`
`
`2008
`
`73074720.2
`
`
`
`IPR2017-01133
`U.S. Patent No. 8,601,506
`
`I.
`
`INTRODUCTION
`All grounds asserted in the Petition rely on Lahti (Ex. 1006) to supply certain
`
`features of each of independent claims 1, 23, and 26, including a server providing
`
`instructions to a client computing device to cause video data to be captured in
`
`accordance with predetermined constraint(s) defined by
`
`the
`
`instructions.
`
`Additionally, all grounds asserted in the Petition rely on Conway (Ex. 1007) to
`
`supply certain features of each of independent claims 1, 23, and 26, including that
`
`the predetermined constraint includes video length.
`
`However, Petitioner has not shown that Ex. 1006 teaches capturing video data
`
`in accordance with predetermined constraints. Additionally, Petitioner has not
`
`shown that Ex. 1006 and Ex. 1007 can be properly combined. All challenged
`
`dependent claims depend from independent claims 1, 23, and 26, and therefore, all
`
`asserted grounds fail to show unpatentability of any challenged claim.
`
`Patent Owner therefore respectfully asks the Board to uphold the patentability
`
`of claims 1, 4-8, 11, 13-15, 23-26, and 29-30.
`
`II. THE ’506 PATENT
`The ’506 Patent discloses “receiving and distributing user-generated video
`
`content.” See Ex. 1001 at Abstract. Specifically, the ’506 Patent provides ways to
`
`facilitate “receiving video data from a client computing device, where the video data
`
`73074720.2
`
`
`
`1
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`is captured using a camera connected to the client computing device in accordance
`
`with instructions executed on the client computing device to provide the video data
`
`in accordance with predetermined constraints.” Id. Figure 1 depicts such a “content
`
`creation and distribution system (CCDS) 100.” Id. at 9:49-50.
`
`
`
`“The CCDS 100 can be provided as a complex set of interconnected software
`
`and server systems.” Id. at 9:50-51. “These software and systems can be used to
`
`record, transcode, transfer, save, and play-back user-generated, digital audio/visual
`
`content so that various end users can upload user-captured and/or user-created digital
`
`audio/visual content from a variety of digital sources for the purpose of airing or
`
`distributing that content through one or more content distribution outlets.” Id. at
`
`9:52-58.
`
`73074720.2
`
`- 2 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`The ’506 Patent discloses that “[t]he video file recording and editing system
`
`guides the user through a video file creation and submission process.” Id. at 3:11-
`
`13. For example, this guidance could happen in the “example of a web-based
`
`recording and uploading user interface” disclosed in Figure 3. Id. at 7:52-53.
`
`
`
`The submission process may include “captur[ing] a video via a video camera
`
`either built-in, or connected to, the user device to create a video file that meets the
`
`requirements for submission to a content distribution sub-system, and submit[ting]
`
`the video file to the content distribution sub-system.” Id. at 3:13-17. In this way,
`
`“[t]he video data is captured using a camera connected to the client computing device
`
`in accordance with instructions executed on the client computing device to provide
`
`the video data in accordance with predetermined constraints.” Id. at 4:10-14.
`
`73074720.2
`
`- 3 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`Further, “[t]he content distribution sub-system can perform electronic filtering
`
`of video files and can automatically transcode the video files into an appropriate
`
`format.” Id. at 3:43-46. This transcoding may be “based upon destination,” for
`
`example “one format if the video content is intended for distribution via linear
`
`television programming and another format if intended for distribution on an Internet
`
`video blog.” Id. at 3:45-49.
`
`III. LEVEL OF ORDINARY SKILL IN THE ART
`The pertinent art is video recording and publishing across a communication
`
`network. Ex. 2002 at ¶ 36.
`
`As of the relevant date, a person of ordinary skill in the art (POSITA) “would
`
`have had a combination of technical education and experience that would have given
`
`such a person a first-hand understanding of the types of tools, particularly web-based
`
`tools, used in video recording and publishing across a communication network.” Id.
`
`at ¶ 37.
`
`Dr. Olivier explains that “[t]he technology addressed in the ’506 Patent was
`
`moderately sophisticated and would have required some experience to fully
`
`appreciate and understand.” Id. at ¶ 38. In general, the problem addressed and
`
`solved by the ’506 Patent was “ensur[ing] that video files are received in one or more
`
`preselected formats and in accordance with predetermined parameters, which can
`
`73074720.2
`
`- 4 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`facilitate automated transcoding . . . into one or more formats appropriate for
`
`selected types of distribution.” See Ex. 1001 at 7:8-14.
`
`Based on these factors, a POSITA would have had a Bachelor of Science in
`
`Electrical Engineering, Computer Engineering, or Computer Science and about two
`
`years of experience in the area of networked video, or equivalent experience and
`
`education. Id. at ¶ 39.
`
`IV. CLAIM CONSTRUCTION
`In construing claim terms, the Board must determine the scope of the claims
`
`by giving them their broadest reasonable interpretation (“BRI”) in light of the
`
`specification as they would be interpreted by one of ordinary skill in the art.1
`
`TriVascular, Inc. v. Samuels, 812 F.3d 1056, 1062 (Fed. Cir. 2016) (citing In re
`
`Cuozzo Speed Techs., 793 F.3d 1268, 1279–80 (Fed. Cir. 2015)). Under the BRI
`
`
`1 On May 9, 2018, the USPTO issued a notice of proposed rulemaking (83 FR 21221)
`
`proposing to amend the rules for IPR proceedings by replacing the BRI standard for
`
`unexpired claims, with an approach that follows Phillips v. AWH Corp., 415 F.3d
`
`1303 (Fed. Cir. 2005) (en banc) (“Phillips standard”). This response first applies
`
`the existing BRI standard to claim construction. If the construction of a term in the
`
`’506 Patent would differ under the Phillips standard in a way that impacts the
`
`analysis set forth herein, a Phillips standard construction is also provided.
`
`73074720.2
`
`- 5 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`standard, words of the claim are given their plain meaning unless it would be
`
`inconsistent with the specification and prosecution history. See Straight Path IP
`
`Grp., Inc. v. Sipnet EU S.R.O., 806 F.3d 1356, 1362 (Fed. Cir. 2015).
`
`It is not reasonable to construe individual words of a claim without
`
`considering the context in which those words appear. See Trivascular, 812 F.3d
`
`at 1062. Instead, it is the “use of the words in the context of the written description
`
`and customarily by those of skill in the relevant art that accurately reflects both the
`
`‘ordinary’ and ‘customary’ meaning of the terms in the claims.” Id. (citing Ferguson
`
`Beauregard/Logic Controls, Div. of Dover Res., Inc. v. Mega Sys., LLC, 350 F.3d
`
`1327, 1338 (Fed. Cir. 2003)).
`
`Patent Owner submits, for purposes of this IPR only, that certain terms of the
`
`’506 Patent should be construed as follows:
`
`A.
`“predetermined constraints” (claims 1, 2, 6, 7, 13, 23, 2)
`A POSITA would have no difficulty understanding the meaning of the term
`
`in view of the intrinsic record. Ex. 2002 at ¶ 50. Petitioner and its expert propose
`
`that the BRI of predetermined constraints is “parameters, rules, or restrictions that
`
`ensure compliance and compatibility with system requirements or goals, including
`
`but not limited to video length, video format type, video image resolution, video
`
`frame rate, or video transmission bit rate, etc.” Pet. at. 9; Ex. 1003 at ¶ 46.
`
`73074720.2
`
`- 6 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`To the extent the petitioner’s construction could be interpreted to mean that
`
`“predetermined constraints” must include all of the listed examples of constraints,
`
`the construction does not properly reflect the BRI of this phrase. Id. at ¶ 51.
`
`Specifically, “predetermined constraints” does not require video length, video
`
`format type, video image resolution, and video transmission bit rate. Id. The
`
`specific recitation in the claims of “frame rate” indicates that (1) “predetermined
`
`constraints” does not require any particular types of constraints, and (2) video length,
`
`video format type, video image resolution, and video transmission bit rate are not
`
`required by the term itself. Id.
`
`Petitioner and its expert do not appear to disagree on this second point, as the
`
`analysis in the Petition and supporting declaration do not attempt to show the
`
`presence of all of the listed types of possible constraints. Id. at ¶ 52. A more-
`
`appropriate version of the Petitioner’s proposed construction is: “parameters, rules,
`
`or restrictions that ensure compliance and compatibility with system requirements
`
`or goals, including examples of which may include but are not limited to video
`
`length, video format type, video image resolution, video frame rate, or video
`
`transmission bit rate, etc.” Id. Patent owner does not agree with the remainder of
`
`the Petitioner’s proposed construction, but further resolution would not
`
`meaningfully change the points analyzed below and, therefore, the remainder of the
`
`Petitioner’s proposed construction is not addressed in detail. Id.
`
`73074720.2
`
`- 7 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`
`B. Other claim terms
`Patent Owner does not concede that Petitioner’s claim constructions are
`
`appropriate. However, the points on which Patent Owner disagrees do not appear to
`
`meaningfully impact Dr. Olivier’s analysis (Ex. 2002 at ¶ 53) or the issues addressed
`
`in detail below. As such Patent Owner does not propose alternate or additional
`
`constructions for purposes of this proceeding.
`
`V. GROUNDS 1-2: LAHTI DOES NOT DISCLOSE A SERVER
`PROVIDING INSTRUCTIONS TO A CLIENT COMPUTING DEVICE
`TO CAUSE VIDEO DATA TO BE CAPTURED IN ACCORDANCE
`WITH PREDETERMINED CONSTRAINT(S) DEFINED BY THE
`INSTRUCTIONS
`Each of Grounds 1-2 relies directly, or through claim dependencies, on
`
`Petitioner’s contention that Lahti (Ex. 1006) “discloses that MobiCon provides
`
`parameters by which the mobile device (on which the application is executing)
`
`captures video data.” Pet. at 27 (citing Ex. 1003 at ¶¶ 105-106) (addressing claim
`
`element 1[c]); see also Pet. at 41 (addressing claim element 23[c] and referring back
`
`to the Petition’s explanation of claim element 1[c]); and Pet. at 46 (addressing claim
`
`element 26[d] and referring back to the Petition’s explanation of claim element 1[c]).
`
`However, Lahti does not disclose this feature either expressly or by implication and,
`
`thus, all of Petitioner’s Grounds necessarily fail. Ex. 2002 at ¶¶ 55, 140-145, 152.
`
`Lahti describes a mobile camera-phone application called MobiCon that can
`
`be used to capture and manage videos. Ex. 1006 at 1. Lahti does not disclose or
`
`73074720.2
`
`- 8 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`suggest that MobiCon has any impact or control over any of the parameters by which
`
`a mobile device captures video data. Ex. 2002 at ¶ 56.
`
`Petitioner cites only one passage of Lahti to support its contention that Lahti
`
`“describes the parameters provided by the app that control the format and frame rate
`
`for the captured video:”
`
`Then, MobiCon’s main screen is displayed (Screenshot 3), where the
`user can choose to view and edit personal information, to load video
`clips, or to capture a new clip (Screenshot 4). 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.
`
`Pet. at 27 (quoting Ex. 1006 at 6) (emphases removed); see also Ex. 1003 at ¶ 105
`
`(same), ¶ 206 (same), ¶ 289 (same), ¶ 301 (same). However, Petitioner’s reliance
`
`on this paragraph as disclosing capturing video on a mobile device according to
`
`predetermined constraints fails for a number of reasons.
`
`A. Lahti does not say MobiCon impacts video-capture parameters
`The passage that Petitioner relies upon does not say what the Petitioner and
`
`its expert, Dr. Houh, contend it means, namely that the MobiCon app governs the
`
`recited video parameters. Ex. 2002 at ¶ 58. The fact that the passage Petitioner cites
`
`from Lahti does not explicitly disclose using the MobiCon app to set or otherwise
`
`impact parameters used to capture video is important, since all digital video data
`
`captured by camera phones or digital cameras necessarily inherently has a format
`
`73074720.2
`
`- 9 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`(e.g., H.263), a resolution (e.g., 176x144), and a frame rate (e.g., 15 frames per
`
`second). Id. Further, in 2006 it was common for camera phones to natively capture
`
`video data in accordance with the Third Generation Partnership Project (“3GPP”)
`
`specification. Id. The 3GPP specification governs capture and transmission of
`
`media over mobile networks, including by using a .3gp multimedia file container
`
`format. Id. For this reason, Lahti’s above-quoted listing of the “3GPP
`
`specification,” “H.263 coding at 176x144 pixels,” and “15 frames per second” is
`
`equally consistent with capturing video using a device’s native capabilities, rather
`
`than capturing video according to parameters set by the MobiCon application. Id.
`
`Additionally, the MobiCon application allows end users to upload video that
`
`has been (1) recorded natively on their mobile device or (2) recorded using the
`
`MobiCon application. Id. at ¶ 59-60. For example, Figure 4 of Lahti shows that
`
`video selected for processing can be either captured using the application, or loaded
`
`from storage on the phone. Ex. 1006 at 5 (“[T]he user can choose . . . to load video
`
`clips, or to capture a new clip.”); see also Ex. 2002 at ¶ 59.
`
`73074720.2
`
`- 10 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`
`
`
`MobiCon thus does not distinguish between uploading natively captured
`
`video or video captured using MobiCon’s “Mobile Media API.” Ex. 1006 at 6; see
`
`also Ex. 2002 at ¶ 60. Because videos that were not captured using MobiCon could
`
`be uploaded using the application, this suggests that Lahti’s MobiCon app would not
`
`have changed the native video capture parameters. Ex. 2002 at ¶ 60. Dr. Olivier
`
`explains:
`
`[I]f videos captured through the MobiCon app changed the native video
`capture parameters, the result would be that videos captured directly
`through the native software would have different parameters, and
`videos of different parameters would be stored on the video server for
`the same user. Therefore, it would have been pointless to constrain the
`parameters of videos captured through the MobiCon application
`because
`the software and server would still be
`transmitting,
`transcoding, and storing videos with the camera phone’s native
`parameters.
`
`Id.
`
`Accordingly, not only does Lahti not disclose capturing video on a mobile or
`
`client device according to predetermined constraints, but a POSITA reviewing Lahti
`
`73074720.2
`
`- 11 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`would understand that the MobiCon application simply used the camera phone’s
`
`native video-capture parameters. Id.
`
`B.
`
`Lahti discloses only one example of MobiCon functionality from
`the user perspective of typical usage scenarios
`As described above, Petitioner’s argument makes much of Lahti’s disclosure
`
`that MobiCon video was “recorded according to 3GPP specification using AMR
`
`coding for audio and H.263 at 176x144 pixels size at 15 frames per second for
`
`video.” Pet. at 27 (quoting Ex. 1006 at 6); see also Ex. 1003 at ¶ 105 (same), ¶ 206
`
`(same), ¶ 289 (same), ¶ 301 (same). However, these video characteristics disclosed
`
`in Lahti are merely an example of “typical usage scenarios”—not parameters that
`
`are required by the MobiCon application. Ex. 2002 at ¶ 61.
`
`Specifically, Lahti’s section 4.3, which contains the passage repeatedly
`
`quoted by Petitioner and its expert, begins: “[t]his section presents the MobiCon
`
`functionality from the user perspective with a walkthrough of typical usage
`
`scenarios.” Ex. 1006 at 6 (emphasis added).
`
`Petitioner’s expert Dr. Houh agrees that Lahti merely provides “an example
`
`of a specific pixel size and frames per second.” Ex. 2008 at 66:13-23 (emphasis
`
`added); see also id. at 67:6-18 (“Sure. It’s an example of what can be done. I
`
`certainly agree that it’s not limiting that MobiCon can only do that.”). Nevertheless,
`
`Dr. Houh contends that “the different characteristics are in fact set by the MobiCon
`
`73074720.2
`
`- 12 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`app,” based in part on his view that Lahti “teach[es] this flexibility, which is that
`
`maybe you can record at a smaller pixel size or a slower frame rate or faster pixel
`
`size or a faster frame rate.” Ex. 2008 at -67:6-68:2. However, contrary to Petitioner
`
`and its expert’s assertion, Lahti does not disclose any such “flexibility.” Ex. 2002
`
`at ¶ 61. Lahti provides a single example of format, resolution, and frame rate, while
`
`never stating or implying that the MobiCon application impacts or controls these or
`
`any other video-capture parameters. Id.
`
`Moreover, Lahti is a technical paper, and thus Lahti’s “walkthrough” “from
`
`the user perspective” would be expected to disclose the characteristics of the video
`
`data captured during application testing and use, even if those characteristics were
`
`not impacted or controlled by the MobiCon application. Id. at ¶ 62. This is because
`
`the paper’s author, while using the MobiCon application, would be interfacing with
`
`the application to start and stop recording of the video, and then would perceive the
`
`video and its characteristics such as resolution and frame rate when drafting the
`
`technical paper. Id.
`
`C. Dr. Houh’s opinion relies on an unsupported assumption about the
`native capabilities of camera phones available in 2006
`During his deposition, Dr. Houh testified that all digital video captured using
`
`a camera phone—for example, when using a third-party application like Facebook—
`
`has a format, a resolution, and a frame rate. Ex. 2008 at 60:22-61:1. Dr. Houh also
`
`73074720.2
`
`- 13 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`conceded that the mere fact that an application enables video capture using a camera
`
`phone does not necessarily indicate that the application governs the format,
`
`resolution, or frame rate during capture. Id. at 61:2-10.
`
`Regardless, Dr. Houh testified that he concluded MobiCon governs the video
`
`capture parameters of the mobile device because he believed the camera phones used
`
`by Lahti were capable of a higher resolution and frame rate than what was disclosed
`
`in the reference. Ex. 2008 at 27:16-18, 78:3-20 (depending on “cameras that if you
`
`just use the native capabilities would record at higher rates” (emphasis added)), and
`
`79:7-12 (confirming that Dr. Houh did not investigate the native capabilities of
`
`camera phones available in 2006); see also id. at 68:3-69:2.
`
`However, a Nokia webpage (i.e., a page published by the manufacturer of the
`
`Nokia 6630) indicates that the only camera phone specifically mentioned in Lahti—
`
`the Nokia 6630—was not capable of recording at a higher resolution than what was
`
`disclosed in Lahti. See Ex. 20052 at 2/4 (under “Video Recorder” heading:
`
`“Resolution: 174 x 144 pixels or 128 x 96 pixels (QCIF or Sub QCIF)”). Further,
`
`the Nokia 6630 recorded natively in .3gp format with H.263 encoding for video and
`
`AMR encoding for audio. Ex. 2005 at 2/4. Because the very video characteristics
`
`
`2 As reflected in its header and footer, this webpage was archived on December 29,
`
`2004. Ex. 1016 at ¶ 5; Ex. 2002 at ¶ 18.
`
`73074720.2
`
`- 14 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`that Dr. Houh contends indicate MobiCon changed the video capture parameters are
`
`in fact the native (i.e., default) parameters used by the only phone disclosed in Lahti,
`
`Dr. Houh’s opinion is not supported by even his own reasoning. Ex. 2002 at ¶ 65.
`
`Lahti’s video capture parameters were native to the Nokia 6630 (and were also native
`
`to other phones at the time), and MobiCon did not need to constrain or alter anything
`
`to cause the Nokia 6630 to capture “according to 3GPP specification using AMR
`
`coding for audio and H.263 at 176x144 pixels size at 15 frames per second for
`
`video.” Id.
`
`Dr. Houh testified that he did not investigate whether any camera phone
`
`(much less the Nokia 6630 mentioned in Lahti) was actually capable of a higher
`
`resolution or frame rate in 2006. See id. at 29:20-30:3, 30:25-31:7. Thus, Dr. Houh’s
`
`reasoning that Lahti teaches capturing according to predetermined constraints is
`
`circular because it was premised on his subjective interpretation of Lahti (id. at 30:4-
`
`21), which in turn was based on his unsupported assumption that “hardware [camera
`
`phones in 2006] were capable of [a higher resolution and frame rate]” (id.).
`
`D. Other publications suggest that Lahti’s recited video-capture
`parameters were standard for camera phones and therefore not
`impacted by MobiCon
`Other publications contemporaneous with Lahti suggest the video parameters
`
`enumerated in Lahti were standard parameters used by camera phones in the 2006
`
`timeframe to capture video data; in at least some instances, these parameters were
`
`73074720.2
`
`- 15 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`non-adjustable. Ex. 2002 at ¶ 67. These facts provide a strong basis for concluding
`
`that Lahti’s MobiCon application did not impact or control the parameters by which
`
`video data was captured. Id. As explained by Dr. Olivier, “these additional
`
`publications suggest that the MobiCon application (the ‘instructions’ on which Dr.
`
`Houh relies) did not define any parameters by which video data was captured, much
`
`less the frame rate.” Id. (emphasis in original).
`
`One such contemporaneous document, Ex. 2003,3 describes the Nokia 6270.
`
`Nokia was a prolific mobile phone manufacturer in the 2006 timeframe. Ex. 2002
`
`at ¶ 68. Ex. 2003 provides a lengthy review of the Nokia 6270 camera phone. The
`
`review indicates the Nokia 6270 captured video data in a “3GP [file] format” at a
`
`“clip resolution of 176x144 pixels” and a frame rate of “15 fps” (i.e. “frames per
`
`second”). Ex. 2003 at 29/44. The review in Ex. 2003 describes that the Nokia 6270
`
`could record videos with “no size restriction. Id. Ex. 2003 also states “you can’t set
`
`another resolution,” indicating that the parameters that controlled video capture
`
`could not be adjusted by an application running on the camera phone. Id.; see also
`
`Ex. 2002 at ¶ 68.
`
`
`3 As reflected in its header and footer, this webpage was archived on February 5,
`
`2006. Ex. 1016 at ¶ 5; Ex. 2002 at ¶ 16.
`
`73074720.2
`
`- 16 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`Another contemporaneous publication, Ex. 2004,4 addresses the Nokia E50.
`
`Ex. 2004 is a review of the Nokia E50 camera phone that indicates the phone
`
`captured video at a resolution of “176x144 [pixels]” and a frame rate of “15 fps.”
`
`Exs. 2003 and 2004 demonstrate that camera phones available in the
`
`timeframe in which Lahti was published captured video with the parameters
`
`disclosed in Lahti (i.e., “at 176x144 pixels size at 15 frames per second” (Ex. 1006
`
`at 6)). Ex. 2002 at ¶ 70. As explained by Dr. Olivier:
`
`This alone strongly suggests that the parameters listed in Lahti were not
`governed or otherwise impacted by Lahti’s MobiCon application. For
`example, even if these parameters were desired, there would have been
`no need to generate code for the MobiCon application to even attempt
`to adjust these parameters when the native software/hardware in then-
`available camera phones generated these parameters without such
`intervention.
`
`Id.
`
`Moreover, Ex. 2003 indicates that, at least for Nokia 6270, the capture
`
`parameters could not be adjusted. Ex. 2003 at 29/44 (“you can’t set another
`
`resolution”). Ex. 2002 at ¶ 71. That at least some camera phones in the relevant
`
`timeframe did not have adjustable parameters for video capture further indicates to
`
`a POSITA that Lahti would not have programmed MobiCon to impact or control
`
`
`4 As reflected in its header and footer, this webpage was archived on May 30,
`
`2006. Ex. 1016 at ¶ 5; Ex. 2002 at ¶ 17.
`
`73074720.2
`
`- 17 -
`
`
`
`Case IPR2017-01133
`Patent 8,601,506
`video capture parameters. Id. This is because, for example, Lahti’s MobiCon
`
`application was intended to be used by many individuals using a variety of mobile
`
`phones. See, e.g., Ex. 1006 at 1/12 (“Mobile phone manufacturers are increasingly
`
`adding new models with multimedia support and most modern medium- to high-
`
`end cell phones come with an integrated audio/video player, a camera to capture
`
`still and moving pictures, and some media editing software.” (emphases added); see
`
`also Ex. 2002 at ¶ 71.
`
`A POSITA in the 2006 timeframe would have sought to minimize aspects of
`
`the MobiCon appli