`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