Paper 50
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________________________
`
`
`TWITTER, INC.
`
`
`
`Petitioner
`
`
`v.
`
`
`VIDSTREAM, LLC
`
`Patent Owner
`
`_____________________________
`
`
`Case IPR2017-01131
`U.S. Patent No. 8,464,304
`(Claims 1, 4-5, 8-9, 11-17, 19-26, and 28-30)
`_____________________________
`
`
`VIDSTREAM LLC’s PATENT OWNER’S RESPONSE
`
`
`73074719.1
`
`

`

`IPR2017-00131
`U.S. Patent No. 8,464,304
`
`TABLE OF CONTENTS
`
`INTRODUCTION ........................................................................................... 1 
`I. 
`THE ’304 PATENT ......................................................................................... 1 
`II. 
`III.  LEVEL OF ORDINARY SKILL IN THE ART ............................................. 4 
`IV.  CLAIM CONSTRUCTION ............................................................................ 5 
`A. 
`“predetermined constraints” (claims 1, 2, 8, 9, 17, 19, 22, 26) ............ 6 
`B. 
`Other claim terms .................................................................................. 7 
`V.  GROUNDS 1-6: PATENTABILITY OF CLAIMS 1, 4-5, 8-9, 11-17,
`19-26, AND 28-30 SHOULD BE UPHELD 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.  GROUND 1: LAHTI AND CURRENT TV REFERENCES ....................... 23 
`VII.  GROUND 2: LAHTI, CURRENT TV, AND WASHINGTON ................... 24 
`VIII.  GROUND 3: LAHTI, CURRENT TV, WASHINGTON, AND
`FRANKEN .................................................................................................... 25 
`IX.  GROUND 4: LAHTI, CHEN, AND ALLEGEDLY ADMITTED
`PRIOR ART ................................................................................................... 25 
`X.  GROUND 5: LAHTI, CURRENT TV, AND ALLEGEDLY
`ADMITTED PRIOR ART ............................................................................. 27 
`XI.  GROUND 6: LAHTI ALONE ...................................................................... 28 
`XII.  CONCLUSION .............................................................................................. 28 
`
`C. 
`
`73074719.1
`
`

`

`IPR2017-00131
`U.S. Patent No. 8,464,304
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`In re Cuozzo Speed Techs.,
`793 F.3d 1268 (Fed. Cir. 2015) ............................................................................ 9
`
`Ferguson Beauregard/Logic Controls, Div. of Dover Res., Inc. v.
`Mega Sys., LLC,
`350 F.3d 1327 (Fed. Cir. 2003) .......................................................................... 10
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) (en banc) ............................................................ 9
`Straight Path IP Grp., Inc. v. Sipnet EU S.R.O.,
`806 F.3d 1356 (Fed. Cir. 2015) ............................................................................ 9
`TriVascular, Inc. v. Samuels,
`812 F.3d 1056 (Fed. Cir. 2016) ...................................................................... 9, 10
`Other Authorities
`83 FR 21221 ............................................................................................................... 9
`
`
`73074719.1
`
`

`

`IPR2017-00131
`U.S. Patent No. 8,464,304
`
`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
`
`73074719.1
`
`

`

`IPR2017-01131
`U.S. Patent No. 8,464,304
`
`I.
`
`INTRODUCTION
`All grounds asserted in the Petition rely on Lahti (Ex. 1006) to supply certain
`
`features of each of independent claims 1, 17, 22, 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.
`
`However, Petitioner has not shown that Ex. 1006 teaches capturing video data
`
`in accordance with predetermined constraints. All challenged dependent claims
`
`depend from independent claims 1, 17, 22, 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-5, 8-9, 11-17, 19-26, and 28-30.
`
`II. THE ’304 PATENT
`The ’304 Patent discloses “receiving and distributing user-generated video
`
`content.” See Ex. 1001 at Abstract. Specifically, the ’304 Patent provides ways to
`
`facilitate “receiving video data from a client computing device, where the 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. Figure 1 depicts such a “content
`
`creation and distribution system (CCDS) 100.” Id. at 9:44-45.
`
`73074719.1
`
`
`
`1
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`
`
`
`“The CCDS 100 can be provided as a complex set of interconnected software
`
`and server systems.” Id. at 9:45-46. “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:47-53.
`
`The ’304 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:6-8.
`
`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:49-50.
`
`73074719.1
`
`- 2 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`
`
`
`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:8-12. 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:6-10.
`
`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:39-41. This transcoding may be “based upon destination,” for
`
`example “one format if the video content is intended for distribution via linear
`
`73074719.1
`
`- 3 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`television programming and another format if intended for distribution on an Internet
`
`video blog.” Id. at 3:42-45.
`
`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 ’304 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 ’304 Patent was “ensur[ing] that video files are received in one or more
`
`preselected formats and in accordance with predetermined parameters, which can
`
`facilitate automated transcoding . . . into one or more formats appropriate for
`
`selected types of distribution.” See ’304 Patent at 7:3-10.
`
`Based on these factors, a POSITA would have had a Bachelor of Science in
`
`Electrical Engineering, Computer Engineering, or Computer Science and about two
`
`73074719.1
`
`- 4 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`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
`
`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).
`
`
`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
`
`’304 Patent would differ under the Phillips standard in a way that impacts the
`
`analysis set forth herein, a Phillips standard construction is also provided.
`
`73074719.1
`
`- 5 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`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
`
`’304 Patent should be construed as follows:
`
`A.
`“predetermined constraints” (claims 1, 2, 8, 9, 17, 19, 22, 26)
`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
`
`provided to ensure compliance and compatibility with system requirements or goals,
`
`including but not limited to video length, video format type, video image resolution,
`
`video transmission bit rate, etc.” Pet. at. 8; Ex. 1003 at ¶ 50.
`
`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. Ex. 2002 at ¶ 51.
`
`Specifically, “predetermined constraints” does not require video length, video
`
`73074719.1
`
`- 6 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`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 provided to 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 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.
`
`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
`
`73074719.1
`
`- 7 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`in detail below. As such Patent Owner does not propose alternate or additional
`
`constructions for purposes of this proceeding.
`
`V. GROUNDS 1-6: PATENTABILITY OF CLAIMS 1, 4-5, 8-9, 11-17, 19-
`26, AND 28-30 SHOULD BE UPHELD BECAUSE 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-6 relies directly, or through claim dependencies, on
`
`Petitioner’s contention that Lahti (Ex. 1006) “teaches that MobiCon provides
`
`parameters by which the mobile device (on which the application is executing)
`
`captures video data.” Pet. at 22 (citing Ex. 1003 at ¶¶ 95-99) (addressing claim
`
`element 1[c]); see also Pet. at 29 (addressing claim element 26[c] and referring back
`
`to the Petition’s explanation of claim element 1[c]); Pet. at 63 (citing Ex. 1003 at
`
`¶¶ 386-398 [see, esp. ¶¶ 389-390]) (addressing claim element 17[b] and referring
`
`back to the Petition’s explanation of claim element 1[c]); Pet. at 69-70 (addressing
`
`claim element 22[b] and referring back to the Petition’s explanation of claim element
`
`17[b]). However, Lahti does not disclose this feature either expressly or by
`
`implication and, thus, all of Petitioner’s Grounds necessarily fail. Ex. 2002 at ¶¶ 54,
`
`80-83, 87-93.
`
`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
`
`73074719.1
`
`- 8 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`suggest that MobiCon has any impact or control over any of the parameters by which
`
`a mobile device captures video data, including a frame rate used to capture video
`
`data. Ex. 2002 at ¶ 55.
`
`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 22 (quoting Ex. 1006 at 6); see also Ex. 1003 at ¶ 97 (same), ¶ 175 (same),
`
`¶ 389 (same), ¶ 458 (same). However, Petitioner’s reliance on this paragraph as
`
`disclosing capturing video on a mobile device according to predetermined
`
`constraints, including a frame rate, 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—including the frame rate—is important,
`
`since all digital video data captured by camera phones or digital cameras necessarily
`
`73074719.1
`
`- 9 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`inherently has a format (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.
`
`73074719.1
`
`- 10 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`
`
`
`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 (including frame rate), but a
`
`73074719.1
`
`- 11 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`POSITA reviewing Lahti 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 22 (quoting Ex. 1006 at 6); see also Ex. 1003 at ¶ 97 (same), ¶ 175
`
`(same), ¶ 389 (same), ¶ 458 (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
`
`app,” based in part on his view that Lahti “teach[es] this flexibility, which is that
`
`73074719.1
`
`- 12 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`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
`
`conceded that the mere fact that an application enables video capture using a camera
`
`73074719.1
`
`- 13 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`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
`
`that Dr. Houh contends indicate MobiCon changed the video capture parameters are
`
`
`2 As reflected in its header and footer, this webpage was archived on December 29,
`
`2004. Ex. 1016 at ¶ 5; Ex. 2002 at ¶ 18.
`
`73074719.1
`
`- 14 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`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 was in turn 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
`
`non-adjustable. Ex. 2002 at ¶ 67. These facts provide a strong basis for concluding
`
`73074719.1
`
`- 15 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`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.
`
`73074719.1
`
`- 16 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`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.
`
`73074719.1
`
`- 17 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`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 application that were dependent on a particular model of phone—i.e.
`
`available operations that differed between phones. Id. at ¶ 72. Lahti itself discloses
`
`that interfacing with a variety of mobile phone models is a challenge: “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.” Ex. 1006 at 3/12. As
`
`Dr. Olivier explains, “[a]ttempting to govern or not govern the video-capture
`
`parameters on an ad-hoc basis depending on the model of camera phone would have
`
`required additional complexity . . . to govern whether or not the video-capture-
`
`parameter code modules would be activated depending on the model of camera
`
`phone.” Ex. 2002 at ¶ 72. As more camera phones are released, such a situation
`
`73074719.1
`
`- 18 -
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`becomes untenable. A POSITA in the timeframe of Lahti would have understood
`
`that variation between camera phones—especially where some phones did not allow
`
`modification of video capture parameters—strongly counseled against Dr. Houh’s
`
`interpretation of the video capture parameters disclosed in Lahti’s “walkthrough.”
`
`Id.
`
`The only model of camera phone identified in Lahti is the Nokia 6630. See
`
`Ex. 1006 at 8/12 (“We lent each of the ten trial participants a Nokia 6630 MCP with
`
`MobiCon preinstalled.”). The Nokia 6630 is described in Exs. 2005-2007. Ex.
`
`2005 is a Nokia webpage that provides the Nokia 6630’s native video capture
`
`parameters, including: “.3gp file format, H.263 video and AMR radio [audio]” at a
`
`resolution of “174 x 144 pixels or 128 x 96 pixels.” Ex. 2005 at 2/4. Other
`
`publications indicate that the default recording parameters on the Nokia 6630 were
`
`176x144 pixels and a frame rate of 15 frames per second (fps)—the same as
`
`disclosed in Lahti.
`
`For example, Ex. 2006 describes that the Nokia 6630 captured video in “3GP”
`
`format, with a resolution of “176x144 pixel[s],” at a frame rate of “15 [frames per
`
`second]”:
`
`Ex. 2006 at 3/7; see also Ex. 2002 at ¶ 19.
`
`73074719.1
`
`- 19 -
`
`
`
`

`

`Case IPR2017-01131
`Patent 8,464,304
`Ex. 20075 fur