throbber
Paper 68
`Trials@uspto.gov
`571-272-7822 Entered: January 23, 2019
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`TWITTER, INC.,
`Petitioner,
`
`v.
`
`VIDSTREAM LLC,
`Patent Owner.
`____________
`
`Case IPR2017-01133
`Patent 8,601,506 B2
`____________
`
`
`
`
`
`
`Before SALLY C. MEDLEY, CHARLES J. BOUDREAU, and
`JESSICA C. KAISER, Administrative Patent Judges.
`
`MEDLEY, Administrative Patent Judge.
`
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`I. INTRODUCTION
`Twitter, Inc. (“Petitioner”) filed a Petition for inter partes review of
`claims 1, 4–8, 11, 13–15, 23–26, 29, and 30 of U.S. Patent No. 8,601,506 B2
`(Ex. 1001, “the ’506 patent”). Paper 1 (“Pet.”). Youtoo Technologies, LLC
`(the original “Patent Owner”) did not file a Preliminary Response. Upon
`consideration of the Petition, we instituted an inter partes review pursuant to
`35 U.S.C. § 314, as to claims 1, 4–8, 11, 13–15, 23–26, 29, and 30 of the
`’506 patent. Paper 8 (“Dec.”).
`Subsequent to institution, VidStream LLC (subsequent “Patent
`Owner”) filed a Patent Owner Response (Paper 47, “PO Resp.”), Petitioner
`filed a Reply to Patent Owner’s Response (Paper 50, “Reply”), and Patent
`Owner filed a Sur-Reply to Petitioner’s Reply (Paper 57, “Sur-Reply”).
`Petitioner filed a Motion to Exclude (Paper 54, “Pet. Mot. Exc.”), Patent
`Owner filed an Opposition (Paper 61, “PO Opp. Mot. Exc.”), and Petitioner
`filed a Reply (Paper 63). Patent Owner filed a Motion to Exclude (Paper 56,
`“PO Mot. Exc.”), Petitioner filed an Opposition (Paper 60, “Pet. Opp. Mot.
`Exc.”), and Patent Owner filed a Reply (Paper 61). An oral hearing was
`held October 19, 2018. A transcript of the hearing has been entered into the
`record. Paper 67 (“Tr.”).
`This Final Written Decision is entered pursuant to 35 U.S.C. § 318(a).
`For the reasons that follow, Petitioner has not shown by a preponderance of
`the evidence that any of the challenged claims are unpatentable.
`
`A. Related Matters
`The parties state that the ’506 patent is the subject of a court
`proceeding styled Youtoo Technologies, LLC v. Twitter, Inc., Case No. 3:16-
`cv-00764-N (N.D. Tex.). Pet. 1; Paper 4, 1.
`
`2
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`Patent Owner at the time, Youtoo Technologies, LLC (“Youtoo”),
`filed for bankruptcy on November 30, 2017. Ex. 2001. During the
`bankruptcy proceeding, the bankruptcy court approved an agreed order to
`sell certain of Youtoo’s property, including the patent challenged in this
`proceeding. Ex. 1027; Ex. 1029. On May 1, 2018, the bankruptcy trustee
`filed a report of sale indicating the challenged patent had been sold to STI-
`ACQ LLC, as assignee of Arundel Ventures LLC. Ex. 1030. On May 7,
`2018, and consistent with the report of sale, new mandatory notices were
`filed indicating STI-ACQ as Patent Owner. Paper 34. On May 18, 2018,
`new mandatory notices were filed indicating that VidStream LLC is the
`current Patent Owner. Paper 36; Paper 41.1 Due to the unusual facts of this
`proceeding, and in accordance with 37 C.F.R. § 42.100(c), the Chief
`Administrative Patent Judge extended the one-year period for issuing a Final
`Written Decision in the present proceeding. Paper 38; Paper 39.
`
`B. The ’506 Patent
`The ʼ506 patent is directed to computer methods and systems for
`receiving and distributing user-generated video content. Ex. 1001, Abstract.
`Figure 2 is reproduced below.
`
`
`1 Except as otherwise noted, “Patent Owner” herein refers to VidStream
`LLC.
`
`3
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`
`Figure 2 shows a content creation and distribution system (CCDS)
`202. Id. at 13:66–67. System 200 can include several servers connected to
`one or more communications network(s) 204. Id. at 13:67–14:2. CCDS 202
`includes a plurality of servers 206, 208, 210, 212, 214, 216, and 218. Id. at
`14:6–11. CCDS 202 communicates with a television distribution system
`220, that can include a network operations center for a television network
`and/or uplink facility from which a television network feed is distributed to
`carriers 228 that provide television services. Id. at 14:24–28. A user having
`a mobile device 230 capable of capturing SD or HD video or a computing
`device 232 having a video camera 234 can connect to the communications
`network(s) 204 and interface with CCDS 202. Id. at 14:37–43. Web hosting
`server 206 provides one or more web pages through which users can access
`services provided by CCDS 202. Id. at 14:43–45. Web hosting server 206
`can host a registration web page that allows users to register with the CCDS
`202 and a HD recorder web page that provides users with access to a thin
`
`4
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`client application (or web application) that supports video capture. Id. at
`14:45–49. Web hosting server 206 also can allow fat client applications to
`be downloaded and installed on mobile device 230 or computing device 232.
`Id. at 14:51–53.
`
`C. Illustrative Claim
`Petitioner challenges claims 1, 4–8, 11, 13–15, 23–26, 29, and 30 of
`the ’506 patent. Claims 1, 23, and 26 are independent claims. Claim 1,
`reproduced below, is illustrative of the claimed subject matter (highlighting
`added for emphasis):
`1. A method performed by data processing apparatus, the
`method comprising:
`receiving video data from a client computing device at a
`server system, wherein the video data is captured using a
`camera communicably connected to the client computing
`device in accordance with instructions executed on the client
`computing device, wherein the instructions are provided to the
`client computing device by the server system and cause the
`video data to be captured in accordance with predetermined
`constraints and the predetermined constraints include a video
`length defined by the instructions, with the video length
`predefined at the server system in accordance with a time slot in
`a linear television programming broadcast;
`transcoding the video data, using a server included in the
`server system, into at least one different format, wherein at least
`one format of the transcoded video data defines a video file in a
`format appropriate for inclusion in the linear television
`programming broadcast; and
`transferring the transcoded video data to a distribution
`server for distribution.
`
`Id. at 27:63–28:17.
`
`5
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`Basis
`
`§ 103
`
`Challenged Claims
`1, 4–8, 11, 13–15, 23–26, 29,
`and 30
`1, 4–8, 11, 13–15, 23–26, 29,
`and 30
`
`D. Instituted Grounds of Unpatentability
`We instituted trial based on all asserted grounds of unpatentability as
`follows (Dec. 15):
`References
`Lahti2, Conway3, and
`Novak4
`Lahti, Novak, Current
`TV Mobile5, and Current
`TV FAQ6
`
`§ 103
`
`II. ANALYSIS
`
`A. Principles of Law
`To prevail in its challenge to Patent Owner’s claims, Petitioner must
`demonstrate by a preponderance of the evidence that the claims are
`unpatentable. 35 U.S.C. § 316(e); 37 C.F.R. § 42.1(d). A claim is
`unpatentable under 35 U.S.C. § 103(a) if the differences between the
`claimed subject matter and the prior art are such that the subject matter, as a
`whole, would have been obvious at the time of the invention to a person
`having ordinary skill in the art. KSR Int’l Co. v. Teleflex, Inc., 550 U.S. 398,
`
`
`2 Janne Lahti et al., “A Mobile Phone-based Context-Aware Video
`Management Application,” Multimedia on Mobile Devices II, Proc. of
`SPIE-IS&T Electronic Imaging, SPIE Vol. 6074, 60740O, 2006 (Ex. 1006)
`(“Lahti”).
`3 U.S. Patent Application Publication No. 2009/0157697 A1, filed Dec. 31,
`2008, published June 18, 2009 (Ex. 1007) (“Conway”).
`4 U.S. Patent Application Publication No. 2002/0104099 A1, filed Dec. 19,
`2000, published Aug. 1, 2002 (Ex. 1008) (“Novak”).
`5 Current TV “create & upload: mobile” webpage (Ex. 1009) (“Current TV
`Mobile”).
`6 Current TV “FAQ” webpage (Ex. 1011) (“Current TV FAQ”).
`6
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`406 (2007). The question of obviousness is resolved on the basis of
`underlying factual determinations including (1) the scope and content of the
`prior art; (2) any differences between the claimed subject matter and the
`prior art; (3) the level of ordinary skill in the art; and (4) objective evidence
`of nonobviousness. Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966).
`
`B. Level of Ordinary Skill
`In determining the level of ordinary skill in the art, various factors
`may be considered, including the “type of problems encountered in the art;
`prior art solutions to those problems; rapidity with which innovations are
`made; sophistication of the technology; and educational level of active
`workers in the field.” In re GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995)
`(citation omitted). Petitioner relies on the testimony of Dr. Henry Houh,
`who testifies that a person with ordinary skill in the art “would possess (i) a
`Bachelor’s degree in Computer Science, Electrical and/or Computer
`Engineering, or equivalent training, and (ii) approximately two years of
`experience in network architecture and multimedia systems, including
`creating and distributing multimedia.” Pet. 6–7 (citing Ex. 1003 ¶ 41). Dr.
`James Olivier, Patent Owner’s declarant, applies a similar definition. PO
`Resp. 4–5 (citing Ex. 2002 ¶ 39).
`For purposes of this decision, we adopt Dr. Houh’s assessment of a
`person with ordinary skill in the art.
`
`C. Claim Construction
`In an inter partes review, we construe claim terms in an unexpired
`patent according to their broadest reasonable construction in light of the
`
`7
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`specification of the patent in which they appear.7 37 C.F.R. § 42.100(b)
`(2016). Consistent with the broadest reasonable construction, claim terms
`are presumed to have their ordinary and customary meaning as understood
`by a person of ordinary skill in the art in the context of the entire patent
`disclosure. In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir.
`2007).
`Petitioner proposes constructions for the following claim terms found
`in the challenged claims: ‘“video length defined by the instructions, with the
`video length predefined at the server system in accordance with a time slot
`in a linear television programming broadcast’ (all claims),” “‘transcoding’
`(all claims),” and “‘buffered on the client computing device using scripts’
`(claim 5).” Pet. 10–12. In our Decision to Institute, we interpreted these
`terms. Dec. 5–7. Neither party has indicated that our interpretations were
`improper, and we do not perceive any reason or evidence that now compels
`any deviation from our initial interpretations. Accordingly, the following
`constructions apply to this Decision: “video length defined by the
`instructions, with the video length predefined at the server system in
`accordance with a time slot in a linear television programming” means
`“computer instructions provided by a server computing device to a client
`computing device that identify a video length suitable for including video
`into a traditional television program or broadcast”; “transcoding” means
`“converting from one video format to another”; and “buffered on the client
`computing device using scripts” means “temporarily storing data in memory
`
`
`7 We would construe the claim term discussed below the same under Phillips
`v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc).
`8
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`of the client computing device using a computer program, software
`application, or other unit of computer code.”
`Petitioner further proposes a construction for “predetermined
`constraints” recited in all of the challenged claims. Pet. 8–9. We
`preliminarily adopted Petitioner’s construction. Dec. 6. Patent Owner
`proposes a “more appropriate version of the Petitioner’s proposed
`construction” as “parameters, rules, or restrictions that ensure compliance
`and compatibility with system requirements or goals, 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.” PO
`Resp. 6–7. Petitioner agrees with Patent Owner’s edits to Petitioner’s
`proposed construction. Reply 1 n.1; Tr. 6:12–21. For purposes of this
`Decision, we adopt Patent Owner’s construction of “predetermined
`constraints.”
`
`D. Obviousness of claims over Lahti, Conway, and Novak
`Petitioner contends claims 1, 4–8, 11, 13–15, 23–26, 29, and 30 are
`unpatentable under 35 U.S.C. § 103(a) as obvious over Lahti, Conway, and
`Novak. Pet. 12–61. In support of its showing, Petitioner relies upon the
`declaration of Dr. Henry Houh. Id. (citing Ex. 1003).
`
`1. Lahti
`Lahti describes a video management system including a video server
`and a mobile camera-phone application called MobiCon. Ex. 1006, 1
`(Abstract). MobiCon allows a user to capture videos, annotate them with
`metadata, specify digital rights management (DRM) settings, upload videos
`over a cellular network, and share the videos with others. Id. Lahti
`
`9
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`describes that the MobiCon application is downloaded over the air to a
`mobile camera-phone. Id. at 5. MobiCon operates on the Candela system
`architecture, which was developed as a solution for general video
`management and includes tools for video creation, analysis, annotation,
`storage, search, and delivery phases. Id. at 4.
`
`
`
`
`Figure 3 of Lahti is a high-level description of MobiCon.
`As shown above, the UploadClient, which is a mobile Java
`application, runs on a mobile phone, and UploadGateway, which is
`implemented as a Java servlet, runs on the server. Id. at 5. The system
`provides wireless access over a mobile phone network to enable storing
`video clips on the server where it is possible to run more computation-
`intensive operations such as video transcoding. Id. Within the UploadClient
`is the UIManager. Id. The UIManager coordinates the video capture using
`the mobile phone’s camera, the saving of the video data to the Java Record
`Store system, the sending of video data to the Java Record Store system, and
`the sending of video sharing SMS messages to the other users. Id. Within
`the UploadGateway is the Video Manager Servlet. Id. at 7. After the video
`
`10
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`clip is uploaded via the UploadGateway, the video clip is handed over to the
`Video Manager Servlet. Id. In the Video Manger Servlet, the video clip is
`transcoded into different formats and bit rates in order to provide a scalable
`service quality for different devices and network connections. Id. The
`Video Manager Servlet prepares Real Video, H.264, and H.263 encoding for
`delivering the captured video content to mobile devices and MPEG-4 file
`format for desktop computers. Id.
`
`
`
`Figure 4 of Lahti is a high-level description of user authentication and
`
`video capturing.
`
`MobiCon functionality permits user authentication and video capture,
`in addition to editing/uploading the video clip. Id. at 6. The user
`authentication and video capture functionalities are illustrated in Figure 4.
`Id. In Figure 4, MobiCon’s main screen is displayed after authentication of
`the user’s username and password. Id. In the main screen, the user has the
`option to capture a new clip (Screenshot 4). Id. 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
`176×144 pixels size at 15 frames per second for video. Id.
`
`11
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`2. Conway
`Conway describes a method and system for creating variable-length
`media clips from a media stream that is received at a media player. Ex. 1007
`¶ 17. The player provides information about the media stream or a program
`that is currently being viewed to a remotely located server to obtain one or
`more rules relating to the creation of media clips. Id. The rules may include
`maximum allowable clip length, as well as limitations on displaying or
`distributing the clip, that are determined based on program name, network,
`or other information that is the source of the clip. Id. The media player
`creates the clip in accordance with received rules, and provides the clip to a
`distribution server for distribution or sharing with other users. Id.
`Limitations of display or distribution of the clip may be contained within
`metadata associated with the clip to allow the distribution server to
`implement the rules for the particular clip. Id.
`
`3. Novak
`Novak describes a system and method to allow presentation of media
`objects to an end user at a client terminal, such as a television set. Ex. 1007
`¶ 10. An individual can upload media objects to a server and specify the
`manner in which the media objects are to be played as a media program to
`an end user, including the scheduling and sequencing of the media objects.
`Id. The client terminal of the end user can be subscribed or provisioned such
`that information related to media objects, such as media program listings,
`can be provided in an electronic program guide. Id. The media program can
`be provided to the end user via a synthetic channel, which can be tuned to or
`selected by the end user. Id.
`
`12
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`4. Discussion
`Petitioner asserts that the combination of Lahti, Conway, and Novak
`describes all of the elements of claims 1, 4–8, 11, 13–15, 23–26, 29, and 30.
`Pet. 12–61. Claim 1 recites “wherein the instructions are provided to the
`client computing device by the server system and cause the video data to be
`captured in accordance with predetermined constraints.”8 Independent
`claim 23 recites a similar phrase, “wherein the user interface is provided in
`accordance with instructions received from a server system and the
`instructions cause the content to be captured in accordance with
`predetermined constraints.”9 Lastly, independent claim 26 recites a similar
`phrase of “one or more servers . . . to: provide instructions for use by the
`user devices for capturing video data in accordance with predetermined
`constraints.”10 Petitioner relies on Lahti to meet these disputed phrases. Pet.
`21–23, 41–42, 46–47.
`Claim 1 also requires that the “predetermined constraints include a
`video length defined by the instructions.” Claims 23 and 26 include similar
`language. Petitioner relies on Conway for its disclosure of “video length
`constraints provided to a client computing device by the server system.”
`Pet. 32; see also id. at 41, 46. We understand, and the record is clear, that
`Petitioner relies on Conway to meet the “video length” limitations of claims
`
`
`8 This phrase is included in what Petitioner refers to as “limitation 1[c].”
`Pet. 25–26.
`9 This phrase is included in what Petitioner refers to as “limitation 23[c].”
`Pet. 41.
`10 This phrase is included in what Petitioner refers to as “limitation 26[d].”
`Pet. 46.
`
`
`13
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`1, 23, and 26, but relies solely on Lahti to meet the claimed instructions
`(provided to the client computing device by the server system) to “cause the
`video data to be captured in accordance with predetermined constraints.”
`Pet. 14 (“This Petition relies on Lahti for disclosing most of the limitations
`of the Challenged Claims. The Petition relies on Conway for its disclosure
`of a maximum allowable clip length.”), 16 (“Incorporating the clip length
`constraint [from Conway] into Lahti would have required only routine
`programming skills . . . .”), Reply 15, 19–20 (“Petitioner does not rely on
`Conway for the client computing device or video capture aspects of the
`Challenged Claims. . . . Petitioner relies on Conway merely for the rule
`(constraint) for limiting video length.”). During oral argument, Petitioner
`confirmed that Conway was relied on for meeting the “video length”
`limitations and not “for the concept of downloading predetermined
`parameters onto the phone . . . that include clip length . . . because that’s
`coming from Lahti.” Tr. 23:16–24:15.
`Accordingly, a dispositive issue of this trial is whether Petitioner has
`shown by a preponderance of the evidence that Lahti describes
`predetermined constraints defined by instructions provided to a mobile
`phone by the server, e.g., downloaded, as required by claims 1, 23, and 26.
`PO Resp. 8–22; Reply 1–14; Tr. 24:6–9, 24:22–25:23, 35:10–12. For the
`reasons that follow, we determine that Petitioner has not shown by a
`preponderance of the evidence that Lahti teaches or suggests the disputed
`phrases of claims 1, 23, and 26.
`Regarding claim 1’s “wherein the instructions are provided to the
`client computing device by the server system,” and similar language of
`claims 23 and 26, Petitioner contends that Lahti’s server provides MobiCon
`
`14
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`to the client computing device (mobile phone). Pet. 26 (citing Ex. 1006, 5),
`41, 46. Petitioner argues that a person having ordinary skill in the art would
`have understood that a mobile application constituted software code that
`controls the operation of a device when executed on that device. Pet. 26
`(citing Ex. 1003 ¶ 103), 41, 46.
`We find that Lahti describes a server that downloads the MobiCon
`application to a mobile phone. Lahti describes that
`MobiCon naturally needs to be easily installed without any extra
`tools or additional instructions. The server allows distribution of
`MobiCon application easily to mobile phone users by using
`Over-The-Air (OTA) specification from the Open Mobile
`Alliance, which enables mobile applications to be downloaded
`and installed over the cellular network.
`
`Ex. 1006, 5. Moreover, we agree with Petitioner’s contentions that a person
`having ordinary skill in the art would have understood that a mobile
`application constitutes software code that controls the operation of a device
`when executed on that device. Pet. 26 (citing Ex. 1003 ¶ 103), 41, 46. We
`find that MobiCon is such an application that includes code, e.g.,
`instructions for controlling at least some aspects of a user’s mobile phone.
`Thus, we determine that Petitioner has shown by a preponderance of the
`evidence that Lahti describes that “instructions are provided to the client
`computing device by the server system” as claimed in claim 1, the similar
`claim language of claim 23, and “one or more servers . . . to: provide
`instructions for use by the user device” as recited in claim 26. Patent Owner
`does not dispute that Lahti describes these portions of the disputed phrases.
`PO Resp. 1.
`
`15
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`Claim 1 also recites that the instructions (provided to the client
`computing device by the server system) “cause the video data to be captured
`in accordance with predetermined constraints.” Claims 23 and 26 recite a
`similar requirement. Petitioner contends that Lahti’s MobiCon provides
`parameters by which the mobile device (on which the MobiCon application
`is executing) captures video data. Importantly, Petitioner contends, “Lahti
`explains that MobiCon captures video using a user interface capture screen
`and further describes the parameters provided by the app that control the
`format and frame rate for the captured video.” Pet. 27 (emphasis added). In
`support of this contention, Petitioner cites to the following passage from
`Lahti:
`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 176×144 pixels size at 15 frames
`per second for video.  
`
`
`Ex. 1006, 6. After explaining that parameters such as video format, video
`resolution, and video frame rate are “predetermined constraints,” Petitioner
`concludes that Lahti “teaches providing instructions that ‘cause the video
`data to be captured in accordance with predetermined constraints.’” Pet. 27
`(citing Ex. 1003 ¶¶ 105–106). Dr. Houh testifies that “[t]he MobiCon app
`provides parameters to the mobile device that control the characteristics of
`the video captured by the device.” Ex. 1003 ¶ 106.
`Patent Owner argues that Petitioner’s contentions are not supported by
`Lahti itself because the passage Petitioner relies on from Lahti does not
`expressly or implicitly describe that the parameters are provided by the
`
`16
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`instructions provided to the client computing device by the server system,
`e.g., the MobiCon application. PO Resp. 8–12. Patent Owner argues that
`the above description of recording video using parameters is equally
`consistent with recording video using a device’s native capabilities, “since
`all digital video data captured by camera phones or digital cameras
`necessarily inherently has a format (e.g., H.263), a resolution (e.g.,
`176×144), and a frame rate (e.g., 15 frames per second).” PO Resp. 9–10
`(citing Ex. 2002 ¶ 58). Patent Owner further argues that it is more likely
`that the parameters came from the device’s native capabilities described in
`the Lahti example. Id. at 12–13 (citing Ex. 1006, 6; Ex. 2002 ¶¶ 60–62).
`We agree with Patent Owner that the passage Petitioner relies on to
`meet the disputed phrase does not describe that the predetermined
`constraints, including frame rate, are defined by the instructions (the
`MobiCon app that was downloaded from a server). Neither the Petition nor
`Petitioner’s expert explains how Lahti meets the disputed phrase; only that it
`does. Pet. 26–27 (citing Ex. 1006, 6; Ex. 1001, 4:40–43, 10:66–11:6;
`Ex. 1003 ¶¶ 103–106). That representation, however, is not supported by
`Lahti itself.
`First, we find that Lahti does not expressly state that the
`predetermined constraints come from the MobiCon application. The above
`passage is within the section styled “4.3 MobiCon Interface Flow
`Diagrams.” Ex. 1006, 6. The first sentence of that section explains, “This
`section presents the MobiCon functionality from the user perspective with a
`walkthrough of typical usage scenarios.” Id. Thus, the passage is within a
`section that describes an example, e.g., a typical usage scenario, “from the
`user perspective.” The second sentence from the above passage states that a
`
`17
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`new video clip “is captured in Capture Screen using Mobile Media API.”
`That same sentence then states “and it [the new video clip] is recorded
`according to 3GPP specification using AMR coding for audio and H.263 at
`176×144 pixels size at 15 frames per second for video.” Notably, Lahti does
`not describe that the new video clip is recorded using parameters
`(instructions, or predetermined constraints) from the MobiCon application or
`even the Mobile Media API, even assuming the Mobile Media API to be
`part of MobiCon11 to record the new clip.
`Second, it is not disputed that the described parameters from the
`above passage, such as format (e.g., H.263), resolution (e.g., 176×144), and
`frame rate (e.g., 15 frames per second) are consistent with recording
`parameters of mobile phones. PO Resp. 9–10 (citing Ex. 2002 ¶ 58), 21;
`Reply 7 (acknowledging that a “POSITA would understand that devices in
`the pertinent timeframe were capable of recording at multiple resolutions
`and frame rates”). Moreover, record evidence shows that in 2006, the year
`Lahti published, technical specifications of the only phone described in
`Lahti—the Nokia 6630—describe as a video format H.263, a resolution of
`176×144 pixels, and a frame rate of 15 frames per second. Ex. 1006, 8;
`Ex. 2005, 2 (describing under “Video Recorder” resolution of “174 × 144”
`pixels and “H.263 video”); Ex. 2006, 3 (describing “Camcorder Resolution”
`as “176×144 pixel” and “15 fps”); Ex. 2007, 3 (describing under “Digital
`Player (Recorder)” “3GP, H.263”).12 These native video capture parameters
`
`
`11 Neither the Petition nor Dr. Houh (Ex. 1003) explains what the Mobile
`Media API is.
`12 As explained below in connection with Petitioner’s Motion to Exclude, we
`disagree with Petitioner that “[e]ach exhibit is hearsay.” Pet. Mot. Exc. 2.
`18
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`of the Nokia 6630 phone, the only described phone in Lahti, are the exact
`same as those described in the above paragraph.
`Thus, the described Lahti parameters could have come from the
`recording parameters of the mobile phone mentioned in the singular
`example. Lahti simply does not state where the parameters originate, and
`neither the Petition nor Dr. Houh’s original declaration provides an
`explanation for why the parameters come from the MobiCon application as
`opposed to somewhere else, like the mobile device. Again, the Petition and
`Petitioner’s expert fail to explain how Lahti meets the disputed phrase; only
`that it does. Pet. 26–27 (citing Ex. 1006, 6; Ex. 1001, 4:40–43, 10:66–11:6;
`Ex. 1003 ¶¶ 103–106). As such, the Petition fails to show by a
`preponderance of the evidence that Lahti meets the disputed phrase.13
`In its Reply, Petitioner directs attention to several new passages in
`Lahti, along with new testimonial evidence to support the position taken in
`the Petition—that Lahti describes the disputed claimed phrase. Reply 2–4
`(citing Ex. 1052 ¶¶ 13–20). For instance, Petitioner argues that a person
`having ordinary skill in the art “would understand Lahti to teach that
`changes are made to mobile phone settings using Software Developer Kits
`[SDKs], which are tools used by the paper’s authors, stating that ‘[v]ideo
`recording . . . is relatively straightforward to implement with vendor
`provided SDKs.’” Reply 10 (citing Ex. 1006, 3). Petitioner further directs
`attention to Dr. Houh’s cross examination deposition where he explains how
`
`
`13 The burden of showing something by a preponderance of the evidence
`simply requires the trier of fact to believe that the existence of a fact is more
`probable than its nonexistence. Concrete Pipe & Prods. of Cal., Inc. v.
`Constr. Laborers Pension Tr. for S. Cal., 508 U.S. 602, 622 (1993).
`19
`
`

`

`IPR2017-01133
`Patent 8,601,506 B2
`
`SDKs and application programming interfaces (APIs) work and how Lahti’s
`mention of SDKs would have been understood to mean that the MobiCon
`application specified parameters, including frame rate, for video capture.
`Reply 10 (citing Ex. 2008, 63:10–68:2, 75:10–76:4, 83:7–86:11, 91:3–20).
`Also in the Reply, Petitioner presents new testimony, explaining the state of
`the art regarding mobile application tools such as operating systems, APIs,
`and SDKs. Reply 12–13 (citing Ex. 1052 ¶¶ 5–16). Moreover, for the first
`time, Petitioner contends in the Reply that the parameters would come from
`the UIManager. Reply 3. Notably, there is no explanation of SDKs, APIs,
`operating systems, or how the parameters come from MobiCon’s
`UIManager in connection with the Petition. There also is no explanation in
`the Petition of how a person having ordinary skill in the art would have
`understood, based on their knowledge of SDKs, APIs, operating systems,
`and MobiCon’s UIManager that Lahti describes the disputed claimed phrase.
`We determine that the Reply as outlined above raises several new issues.
`In its Petition, Petitioner points to a single paragraph from Lahti as
`meeting the disputed claim language, without explaining how the paragraph
`meets the disputed claim language. Pet. 26–27 (citing Ex. 1006, 6; Ex. 1003
`¶¶ 103–106). Petitioner’s Reply provides much more explanation and
`evidence that are missing from the Petition under the guise of responding to
`Patent Owner’s Response. We determine, however, that such explanation
`and evidence, which raises new issues, should have been presented in the
`context of the Petition. Accordingly, we need not and do not consider the
`new evidence and new arg

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


Or .

Accessing this document will incur an additional charge of $.

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

Accept $ Charge
throbber

Still Working On It

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

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

throbber

A few More Minutes ... Still Working

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

Thank you for your continued patience.

This document could not be displayed.

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

Your account does not support viewing this document.

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

Your account does not support viewing this document.

Set your membership status to view this document.

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

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

Become a Member

One Moment Please

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

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

Your document is on its way!

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

Sealed Document

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

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


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket