throbber
Trials@uspto.gov
`571-272-7822
`
`Paper 38
`Entered: January 11, 2022
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`SONY INTERACTIVE ENTERTAINMENT LLC,
`Petitioner,
`v.
`INTELLECTUAL PIXELS LIMITED,
`Patent Owner.
`
`IPR2020-01248
`Patent 8,667,093 B2
`
`
`
`
`
`
`
`
`
`Before JENNIFER S. BISK, JENNIFER MEYER CHAGNON, and
`IFTIKHAR AHMED, Administrative Patent Judges.
`AHMED, Administrative Patent Judge.
`
`JUDGMENT
`Final Written Decision
`Determining Some Non-disclaimed Challenged Claims Unpatentable
`35 U.S.C. § 318(a)
`
`
`
`
`
`
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`
`INTRODUCTION
`I.
`Sony Interactive Entertainment LLC (“Petitioner”) requested an inter
`partes review of claims 1–9, 13, and 15–19 of U.S. Patent No. 8,667,093 B2
`(Ex. 1001, “the ’093 patent”). Paper 3 (“Petition” or “Pet.”). Intellectual
`Pixels Limited (“Patent Owner”) filed a Preliminary Response. Paper 9
`(“Prelim. Resp.”). In its Preliminary Response, Patent Owner informed us
`that it had disclaimed claims 5–9, 13, and 15–19. Id. at 1, n.1 (citing
`Ex. 2001 (Notice of Filing a Statutory Disclaimer of Claims in a Patent
`under 37 C.F.R. § 1.321(a))). Applying the standard set forth in 35 U.S.C.
`§ 314(a), we instituted an inter partes review of claims 1–4 (the “Challenged
`Claims”) of the ’093 patent. Paper 12 (“Inst. Dec.”).
`After institution, Patent Owner filed a Patent Owner Response
`(Paper 19, “PO Resp.”), Petitioner filed a Reply to Patent Owner’s Response
`(Paper 21, “Pet. Reply”), and Patent Owner filed a Sur-reply (Paper 28, “PO
`Sur-reply”). With our authorization (Paper 28), Petitioner filed a
`Supplemental Reply (Paper 30, “Pet. Supp. Reply”). An oral hearing was
`held on October 15, 2021, and a copy of the transcript was entered in the
`record. Paper 37 (“Tr.”).
`We have jurisdiction pursuant to 35 U.S.C. § 6. This Decision is a
`Final Written Decision under 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73 as to
`the patentability of the claims on which we instituted trial. Petitioner bears
`the burden of proving unpatentability of the Challenged Claims, and the
`burden of persuasion never shifts to Patent Owner. Dynamic Drinkware,
`LLC v. Nat’l Graphics, Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015). To
`prevail, Petitioner must prove unpatentability by a preponderance of the
`evidence. See 35 U.S.C. § 316(e) (2018); 37 C.F.R. § 42.1(d) (2019).
`Having reviewed the arguments and the supporting evidence, we determine
`
`2
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`that Petitioner has shown, by a preponderance of the evidence, that claims
`1–3 are unpatentable, but has not shown, by a preponderance of the
`evidence, that claim 4 of the ’093 patent is unpatentable.
`
`II. BACKGROUND
`A. Related Proceedings
`The ’093 patent is asserted in Intellectual Pixels Ltd. v. Sony
`Interactive Entertainment LLC, No. 8:19-cv-01432 (C.D. Cal. filed July 25,
`2019). Pet. 1; Paper 4, 2. That proceeding has been stayed pending
`resolution of this inter partes review. Paper 8, 2.
`B. The ’093 Patent (Ex. 1001)
`The ’093 patent, titled “Image Display System with Visual Server,”
`was filed on November 15, 2011, and claims priority to a provisional
`application filed on January 24, 2001. Ex. 1001, codes (22), (54), (60), (63).
`The ’093 patent issued on March 4, 2014. Id. at code (45).
`The ’093 patent relates to computer graphics and a graphical image
`display system that uses a visual server to generate and transmit images to
`clients. Id. at 1:19–21. The ’093 patent explains that display of three-
`dimensional (“3D”) images at a client requires dedicated graphics hardware
`not available on consumer client devices such as personal digital assistants,
`mobile telephones, and television set-top boxes. Id. at 3:9–12. The ’093
`patent invention seeks to display complex three-dimensional graphics, such
`as those used by games, on such consumer client devices by utilizing the
`resources of a visual server. Id. at 3:12–17.
`
`3
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`Figure 1 of the ’093 patent is reproduced below.
`
`
`
`Figure 1 shows image display system 10 with visual server 12 and
`associated components in communication with a plurality of clients (i.e.,
`television 16 with set-top box 22, PDA 18, and cellular telephone 20) across
`a network. Id. at 4:61–64; 5:13–29.
`The ’093 patent explains that the visual server runs standard software,
`such as games, and further supports software modified to enable control of
`an application from a client and the delivery of a result of 3D drawing to a
`
`4
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`client. Id. at 3:26–29. Visual server 12 selectively receives image-
`modifying data from a client (16, 18, or 20) corresponding to a generated
`image. Id. at 6:3–7. The server then generates a modified image based upon
`the image-modifying data, compresses the image or image data with a
`specific compression/decompression algorithm (“codec”), and transmits the
`compressed data back to the client. Id. at 6:7–12. The client decompresses
`the received image data and displays the image on a display (24, 26, or 28).
`Id. at 6:24–28. The ’093 patent explains that any industry standard codecs,
`such as MPEG, JPEG, and H.261 may be used to compress data at the
`server. Id. at 6:28–31.
`C. Challenged Claims
`Petitioner challenges independent claim 1 and dependent claims 2–4.
`Claim 1 is reproduced below.
`1. A method of playing interactive games on a client device
`having an image display, comprising:
`sending user input control signals to an application,
`running on a server, which generates 3-dimensional graphics
`accordingly;
`receiving, from said server, said 3-dimensional graphics in
`the form of a compressed stream of images;
`decompressing said compressed stream of images into at
`least one decompressed image at said client device, said at least
`one decompressed image corresponding to said graphics; and
`displaying said at least one decompressed image at the
`display of said client device, wherein said client device does not
`perform 3-dimensional graphics processing on said at least one
`decompressed image, and wherein said client device is separate
`from said server.
`Ex. 1001, 9:23–38.
`
`5
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`D. The Instituted Grounds of Unpatentability and Declaration Evidence
`As against the claims remaining after Patent Owner’s disclaimer,
`Petitioner asserts the following grounds of unpatentability, relying on the
`declaration testimony of Dr. Henry Fuchs (Exs. 1002, 1035). Pet. 3, 24–74;
`Pet. Reply 2–27.
`Claims Challenged
`1–3
`1–3
`4
`
`35 U.S.C. §1
`103(a)
`103(a)
`103(a)
`
`Reference(s)/Basis
`Schmidt2
`Schmidt, Keslin3
`Schmidt, IEEE 802.3 Standard4
`Schmidt, Keslin, IEEE 802.3
`Standard
`
`4
`
`103(a)
`
`Patent Owner supports its arguments with a Declaration by John C.
`Hart, Ph.D. (Ex. 2016).
`
`III. ANALYSIS
`
`A. Principles of Law
`“In an [inter partes review], the petitioner has the burden from the
`onset to show with particularity why the patent it challenges is
`unpatentable.” Harmonic Inc. v. Avid Tech., Inc., 815 F.3d 1356, 1363 (Fed.
`
`
`1 Because the ’093 patent issued from a patent application that was filed
`before March 16, 2013, patentability is governed by the version of 35 U.S.C.
`§ 103 preceding the Leahy-Smith America Invents Act (“AIA”), Pub L. No.
`112–29, 125 Stat. 284 (2011).
`2 Brian K. Schmidt et al., The Interactive Performance of SLIM: a Stateless,
`Thin-Client Architecture, 17TH ACM SYMPOSIUM ON OPERATING SYSTEMS
`PRINCIPLES (SOSP ’99), Dec. 12–16, 1999, at 32 (Ex. 1004, “Schmidt”).
`3 U.S. Patent No. 7,274,368 B1, issued Sept. 25, 2007 (Ex. 1005, “Keslin”).
`4 THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, INC., LOCAL
`AREA NETWORKS, CARRIER SENSE MULTIPLE ACCESS WITH COLLISION
`DETECTION, ANSI/IEEE STD. 802.3–1985, ISO/DIS 8802/3 (1985)
`(Ex. 1006, “IEEE 802.3 Standard”).
`
`6
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`Cir. 2016) (citing 35 U.S.C. § 312(a)(3) (requiring inter partes review
`petitions to identify “with particularity . . . the evidence that supports the
`grounds for the challenge to each claim”)). That burden of persuasion never
`shifts to Patent Owner. See Dynamic Drinkware, 800 F.3d at 1378
`(discussing the burden of proof in inter partes review).
`As set forth in 35 U.S.C. § 103(a),
`[a] patent may not be obtained . . . if the differences between the
`subject matter sought to be patented and the prior art are such
`that the subject matter as a whole would have been obvious at the
`time the invention was made to a person having ordinary skill in
`the art to which said subject matter pertains.
`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) when in evidence, objective
`evidence of nonobviousness.5 Graham v. John Deere Co., 383 U.S. 1, 17–
`18 (1966). An obviousness analysis “need not seek out precise teachings
`directed to the specific subject matter of the challenged claim, for a court
`can take account of the inferences and creative steps that a person of
`ordinary skill in the art would employ.” KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398, 418 (2007); accord In re Translogic Tech., Inc., 504 F.3d
`1249, 1259 (Fed. Cir. 2007). However, Petitioner cannot satisfy its burden
`of proving obviousness by employing “mere conclusory statements.” In re
`Magnum Oil Tools Int’l, Ltd., 829 F.3d 1364, 1380 (Fed. Cir. 2016).
`Instead, Petitioner must articulate a reason why a person of ordinary skill in
`
`
`5 Neither party presents evidence of objective considerations of
`nonobviousness.
`
`7
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`the art would have combined the prior art references. In re NuVasive,
`842 F.3d 1376, 1382 (Fed. Cir. 2016).
`B. Level of Ordinary Skill in the Art
`We review Petitioner’s asserted obviousness grounds in view of the
`understanding of a person of ordinary skill in the art at the time of the
`invention. Graham, 383 U.S. at 17. Petitioner contends that a person of
`ordinary skill in the art would have had “at least (1) an undergraduate degree
`in computer science, electrical engineering, or an equivalent subject,
`together with two years of post-graduate experience in computer graphics; or
`(2) a master’s degree in computer science, electrical engineering, or
`equivalent subject, together with one year of postgraduate experience in
`computer graphics.” Pet. 18 (citing Ex. 1002 ¶¶ 25–27). Patent Owner
`agrees with Petitioner but adds that “the experience in computer graphics
`would include experience with multimedia systems, particularly the delivery
`of video display information across a network.” PO Resp. 10–11 (citing
`Ex. 2016 ¶ 26).
`We determine that Petitioner’s proposed level of ordinary skill is
`consistent with the ’093 patent and the asserted prior art, and also agree with
`Patent Owner’s assertion regarding the relevant experience. See Okajima v.
`Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001); In re GPAC Inc., 57 F.3d
`1573, 1579 (Fed. Cir. 1995); In re Oelrich, 579 F.2d 86, 91 (CCPA 1978).
`Accordingly, we determine that one of ordinary skill in the art at the time of
`the invention would have had at least (1) an undergraduate degree in
`computer science, electrical engineering, or an equivalent subject, together
`with two years of post-graduate experience in computer graphics; or (2) a
`master’s degree in computer science, electrical engineering, or equivalent
`subject, together with one year of postgraduate experience in computer
`
`8
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`graphics. The experience in computer graphics would include experience
`with multimedia systems, particularly the delivery of video display
`information across a network.
`C. Claim Construction
`In this inter partes review, claims are construed using the same claim
`construction standard that would be used to construe the claims in a civil
`action under 35 U.S.C. § 282(b). See 37 C.F.R. § 42.100(b) (2019). The
`claim construction standard includes construing claims in accordance with
`the ordinary and customary meaning of such claims as understood by one of
`ordinary skill in the art at the time of the invention. See id.; Phillips v. AWH
`Corp., 415 F.3d 1303, 1312–14 (Fed. Cir. 2005) (en banc). In construing
`claims in accordance with their ordinary and customary meaning, we take
`into account the specification and prosecution history. Phillips, 415 F.3d at
`1315–17. Additionally, only terms that are in controversy need to be
`construed, and these need be construed only to the extent necessary to
`resolve the controversy. See Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`200 F.3d 795, 803 (Fed. Cir. 1999) (holding that “only those terms need be
`construed that are in controversy, and only to the extent necessary to resolve
`the controversy”); Nidec Motor Corp. v. Zhongshan Broad Ocean Motor
`Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017) (citing Vivid Techs. in the context
`of an inter partes review).
`1. 3-dimensional graphics (and related terms)
`The parties inform us of certain terms that were construed in pending
`district court litigation. See Pet. 17 (citing Ex. 1013, 21); PO Resp. 12–13
`(citing Ex. 1013, 12–13). We determine that it is not necessary to expressly
`construe any of these terms for purposes of our Decision.
`
`9
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`2. compressed stream of images
`Patent Owner contends that “[t]he Board does not need to construe
`‘compressed stream of images’ beyond the simple recognition that it does
`not include the color-component subsampling of Schmidt,” “because at the
`time of the invention, color-component subsampled video was considered to
`be uncompressed.” PO Resp. 13–14 (citing Ex. 2016 ¶¶ 45–52, 55–69).
`Petitioner responds that “neither the intrinsic nor extrinsic evidence supports
`Patent Owner’s narrow construction of ‘compressed stream of images’ to
`exclude color component subsampling,” and that “the term should be given
`its plain and ordinary meaning, which indisputably includes the type of
`image compression described in Schmidt.” Pet. Reply 8 (citing Ex. 1035
`¶¶ 29–32, 34).
`Because we find challenged claims 1–3 unpatentable as obvious over
`the combination of Schmidt and Keslin (where Petitioner relies on Keslin as
`teaching a compressed stream of images), we do not reach Petitioner’s
`obviousness ground based on Schmidt alone, and therefore, we do not find it
`necessary to resolve the parties’ claim construction dispute, which relates
`solely to assessing Schmidt’s teaching of the compressed stream of images.
`3. sending user input signals to an application
`The parties also present a claim construction dispute as to the claim
`limitation “sending user input control signals to an application, running on a
`server, which generates 3-dimensional graphics accordingly,” which we
`address below to the extent necessary to conduct our obviousness analysis.
`See infra § III.E.1.b.
`
`10
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`D. Overview of the Asserted Prior Art
`1. Schmidt (Ex. 1004)
`Schmidt discloses a thin-client architecture known as SLIM (Stateless,
`Low-Level Interface Machine) with the goal of removing all state and
`computation from the desktop and using a low-level hardware and software
`independent protocol to connect client devices to the system’s computational
`resources over a low-cost commodity network. Ex. 1004, 33.
`Figure 1 of Schmidt is reproduced below.
`
`
`
`Figure 1 illustrates the main components of the SLIM architecture. Id. at 33.
`The system includes servers and consoles, where consoles transmit keyboard
`and mouse state events to servers via the SLIM protocol, and servers
`transmit audio data and display updates to consoles also via the SLIM
`protocol. Id. at 35. The servers and consoles are connected via an
`interconnection fabric. Id. at 34. For display updates, the SLIM servers
`send only encoded pixel updates to consoles, and each console refreshes its
`display from a local frame buffer using the received display update. Id.
`Schmidt also defines a set of display commands that “compress pixel data by
`
`11
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`taking advantage of the redundancy commonly found in the pixel values
`generated by modern applications.” Id. at 35. One such command, CSCS, is
`used to “[c]olor-space convert [a] rectangular region from YUV to RGB
`with optional bilinear scaling.” Id.
`Schmidt discloses that the performance of the SLIM architecture was
`evaluated on multimedia applications, including a 3-D game from
`id Software known as Quake. Id. at 36. Schmidt details the implementation
`of Quake on the SLIM architecture using “a translation layer which converts
`frames to a format suitable for use by the SLIM CSCS protocol command.”
`Id. at 45.
`2. Keslin (Ex. 1005)
`Keslin discloses a system for remote rendering of computer graphics.
`Ex. 1005, 1:36–38. The system includes a graphics application program,
`resident at a remote server that is run by a client process. Id. at 1:38–41.
`
`12
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`Figure 1 of Keslin is reproduced below.
`
`
`Figure 1 illustrates an overall architecture for Keslin’s system. Id. at 3:30–
`31. Client 103 issues commands 107 to remotely located server 109 to
`perform remote rendering. Id. at 3:31–34. In response, application 120
`generates graphics instructions 125, which are the modified by remote
`rendering control system 130 based on the graphics processing capabilities
`and graphic contexts of specific client 103. Id. at 3:38–51. Graphics
`resources 140 at the server then renders images based on the modified
`graphics instructions and returns image data 145. Id. at 3:51–53. As part of
`the rendering, image data 145 is compressed to form compressed image
`data 150 which is sent to the client. Id. at 3:54–57.
`
`13
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`Figure 3 of Keslin is reproduced below.
`
`
`Figure 3 is a flowchart that illustrates the method of remote rendering of
`computer graphics in Keslin. Id. at 2:15–16. As part of the method of
`remote rendering, at 350, image data is compressed into compressed image
`data. Id. at 5:5–6. At 355, the compressed image data is transmitted to the
`client. Id. at 5:6–7.
`
`14
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`Figure 11 of Keslin is reproduced below.
`
`
`Figure 11 is a flowchart illustrating the remote rendering process from the
`perspective of the client. Id. at 2:36–38. As part of the method of remote
`rendering, at 1125, image data is decompressed at the client. Id. at 7:55–56.
`At 1130, the appropriate image is drawn to a window at the client. Id. at
`7:56–57.
`3. IEEE 802.3 Standard (Ex. 1006)
`The IEEE 802.3 Standard discloses a standard published in 1983 by
`the Institute of Electrical and Electronics Engineers relating to the Carrier
`Sense Multiple Access with Collision Detection (“CSMA/CD”) media
`
`15
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`access method by which two or more stations share a common bus
`transmission medium. Ex. 1006, 13. The IEEE 802.3 Standard discloses
`that “[w]henever the medium is busy, the CSMA/CD MAC sublayer defers
`to the passing frame by delaying any pending transmission of its own.” Id.
`at 38. That delay is referred to by the IEEE 802.3 Standard as
`interFrameSpacing. Id. at 38–39.
`
`E. Obviousness over Schmidt and Keslin
`Petitioner contends that claims 1–3 are unpatentable under 35 U.S.C.
`§ 103 as obvious over Schmidt and Keslin. Pet. 59–68. To support its
`contentions, Petitioner provides, among other things, explanations as to how
`the prior art teaches each claim limitation. Id. Petitioner also relies upon
`Dr. Fuchs’s testimony (Exs. 1002, 1035) to support its positions. Id.
`Patent Owner argues that Petitioner’s proposed obviousness
`combination fails to address Schmidt’s teaching away from adding further
`computation to Schmidt’s client and the fundamental differences in the
`Schmidt and Keslin systems. PO Resp. 45–49. On the complete record, we
`are persuaded by Petitioner’s explanations and evidence in support of the
`obviousness ground for claims 1–3 over Schmidt and Keslin. We address
`below the evidence, analysis, and arguments presented by the parties.
`1. Independent Claim 1
`a) “A method of playing interactive games on a client device
`having an image display, comprising:”
`Petitioner contends Schmidt discloses a method of playing interactive
`games on a client device having an image display. Pet. 24–25 (citing
`Ex. 1002 ¶ 55). Petitioner argues that Schmidt discloses the SLIM client-
`server system comprising both servers and consoles. Id. at 25–26 (citing
`Ex. 1004, 33, Fig. 1; Ex. 1002 ¶ 56). Petitioner further contends that the
`
`16
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`consoles disclosed in Schmidt are thin clients, which are simple desktop
`machines with an image display, that access a shared pool of computational
`resources over a dedicated interconnection fabric. Id. at 26 (citing Ex. 1004,
`Abstract, 35, Fig. 1).
`Petitioner contends that Schmidt further discloses a method of playing
`Quake, an interactive 3D game, on the SLIM console. Pet. 27 (citing
`Ex. 1004, Abstract, 36, 44, 45, 46; Ex. 1002 ¶ 58). Petitioner further
`contends Quake is an interactive game where the player interacts with the
`game by controlling the character within a 3D world. Id. at 27–28 (citing
`Ex. 1009, 39; Ex. 1002 ¶ 59).
`Patent Owner does not specifically respond to these arguments. See
`generally PO Resp. On the complete record, we find that Petitioner provides
`sufficient evidence that Schmidt teaches the preamble of claim 1.6
`b) “sending user input control signals to an application, running
`on a server, which generates 3-dimensional graphics
`accordingly;”
`Petitioner contends Schmidt teaches or suggests sending user input
`control signals to an application, running on a server, which generates
`3-dimensional graphics accordingly. Pet. 28 (citing Ex. 1002 ¶ 61).
`Petitioner contends Schmidt discloses that the SLIM console (i.e., the client
`device) sends user input control signals in the form of mouse and keyboard
`inputs to the SLIM server. Id. at 28–29 (citing Ex. 1004, 33, Fig. 1;
`Ex. 1002 ¶ 62). Petitioner further contends that the “mouse/keyboard events
`& other input” shown in Schmidt’s Figure 1 are types of user input control
`
`
`6 Although we need not decide whether the preamble of claim 1 is limiting,
`Petitioner has shown that the recitation in the preamble is satisfied by the
`prior art.
`
`17
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`signals because Schmidt refers to those signals as “input” and “input
`events.” Id. at 29 (citing Ex. 1004, 33, 37, 38; Ex. 1002 ¶ 63). According to
`Petitioner, Schmidt discloses that the SLIM consoles operate by “passing
`keyboard and mouse state” to the servers, which respond by updating the
`display. Id. at 29–30 (citing Ex. 1004, 35, 37, 38).
`Next, Petitioner argues that Schmidt explains that its “user input
`control signals” are sent to an application running on the SLIM server,
`which, according to Petitioner, is “an application, running on a server,” as
`claim 1 requires. Pet. 30 (citing Ex. 1004, 33, 35). Petitioner points to
`Table 2 of Schmidt as showing various applications that run on the SLIM
`servers, including applications that generate 3-dimensional graphics, such as
`the 3D Quake game. Id. at 30–32 (citing Ex. 1004, 36 (Table 2), 44;
`Ex. 1002 ¶¶ 65–66).
`Petitioner argues that Schmidt discloses that when using SLIM
`architecture to play Quake on a SLIM client, the client sends keyboard and
`mouse input control signals to the SLIM server running the Quake
`application, which in response, generates 3D graphics for display on the
`SLIM client, thus “generat[ing] 3-dimensional graphics” based on the user
`input control signals. Pet. 32 (citing Ex. 1004, 35, 44, 45). Petitioner argues
`that in Quake, the 3D graphics are changed as the player moves around in
`the game, and a person of ordinary skill in the art would understand from
`Schmidt’s disclosure that mouse and keyboard inputs are sent from the
`SLIM console to the SLIM server, where they cause the Quake game
`application running on the server to generate 3D graphics based on the
`inputs. Id. at 33 (citing Ex. 1009, 39; Ex. 1002 ¶ 67).
`Patent Owner responds that claim 1 requires that the server itself, as
`opposed to an application running on the server, generates 3-dimensional
`
`18
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`graphics. PO Resp. 51. Specifically, Patent Owner argues that the first
`limitation of claim 1 recites three requirements, with the third requirement,
`“the server generat[ing] 3-dimensional graphics,” being separate from the
`first two. Id. For support, Patent Owner points to the very next limitation of
`claim 1 as confirming that “it is the server (not the application) generating
`the graphics, as it specifies ‘receiving, from said server, said 3-dimensional
`graphics . . . .’” Id. at 51–52 (citing Ex. 1001, 9:28). Patent Owner also
`cites various portions of the ’093 patent specification to argue that it is the
`server, not the application, that generates a modified image. Id. at 52 (citing
`Ex. 1001, 1:18–21, 3:22–37, 5:43–48, 6:3–20, 6:63–67, 7:38–41).
`Patent Owner’s annotated version of Figure 3 of the ’093 patent is
`reproduced below.
`
`
`Patent Owner’s annotations to Figure 3, above, show the “Application”
`component of server highlighted in blue and “Graphics API” component of
`the server highlighted in green. PO Resp. 53. Patent Owner argues that the
`
`19
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`application component sends drawing commands to the graphics application
`programming interfaces (“API”), which can be one of the industry standard
`APIs, such as Direct3D or OpenGL, and the server uses its 3D graphics
`processing capabilities to generate the “Final Image.” Id. at 53 (citing Ex.
`1001, 5:43–48, 8:54–62, Fig. 3). Patent Owner argues that because the
`application merely sends commands to the Graphics API, it is the server that
`generates the 3D graphics. Id. at 53–54.
`In our Institution Decision, we rejected Patent Owner’s arguments as
`unsupported in view of the plain language of claim 1 and the disclosure of
`the ’093 patent. Inst. Dec. 20–21. We noted that the claim recites “an
`application, running on a server, which generates 3-dimensional graphics
`accordingly.” Id. at 20. Rather than Patent Owner’s narrow reading of this
`limitation, requiring the server to generate 3-dimensional graphics
`independently from the claimed application, we determined that a more
`reasonable construction of this limitation is that the server in its entirety,
`including the application running on the server, generates the 3-dimensional
`graphics. Id. In other words, the phrase “which generates 3-dimensional
`graphics accordingly” cannot be read separately from the first two phrases of
`the limitation in the manner that Patent Owner proposes. Id.
`Patent Owner argues that our preliminary construction was improper
`because it “read[s] out the term ‘application’ by lumping together the
`‘application’ and the ‘server,’” “effectively re-writ[ing] the limitation
`‘sending user input control signals to an application, running on a server,
`which generates 3-dimensional graphics accordingly . . . .’ as ‘sending user
`input control signals to a server, which generates 3-dimensional graphics
`accordingly . . . .’” PO Resp. 54; see also PO Sur-reply 20. We disagree.
`Claim 1 plainly requires “sending user input control signals to an
`
`20
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`application,” and requires that that application run on a server. The claim
`language, however, does not clearly distinguish between the two
`components for the purposes of generating the 3-dimensional graphics, and
`we therefore, gave the limitation its more reasonable interpretation in light
`of the specification, i.e., not limiting the claim to either the application or the
`server alone as generating the 3-dimensional graphics.7
`Patent Owner’s interpretation on the other hand would limit the
`application from having any role in generating the 3-dimensional graphics.
`Patent Owner acknowledges that the claimed application at least sends
`“drawing commands” for the 3-dimensional graphics to the Graphics API
`(see Ex. 1001, 8:59–61, Fig. 3), but argues that that functionality is “no more
`a part of generating 3-dimensional graphics than placing a pizza delivery
`order is a part of making the pizza.” PO Resp. 45 (citing Ex. 2016 ¶ 98). So
`long as the specification requires the application to play some part in
`generating 3-dimensional graphics, we are not persuaded to limit the claim
`in the manner proposed by Patent Owner, which excludes any participation
`by the application. See Ex. 1035 ¶ 71 (testifying that a person of ordinary
`skill in the art “would have understood that an ‘application, running on a
`server’ generates the 3D graphics by instructing the server to do so,” either
`by calling an API like OpenGL or implementing other instructions for the
`server’s CPU to process); Pet. Reply 20–21.
`
`
`7 As we explained in our Institution Decision, the Specification uses the term
`“server” broadly to refer to the entire server component shown in Figure 3,
`not just select components of the server as Patent Owner proposes. See Inst.
`Dec. 21 (citing Ex. 1001, 3:33–34, 5:32–34, 7:14–8:33, Figs. 2, 3). As
`illustrated in Figure 3 of the ’093 patent, the application is illustrated as
`being a part of the server.
`
`21
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`In view of our interpretation of the claim limitation, Patent Owner’s
`argument that Schmidt fails to teach this limitation because the Quake
`application in Schmidt does not use the server’s graphics API or graphics
`processing capability is not persuasive. PO Resp. 55–57 (citing Ex. 1004, 4,
`44–45; Ex. 2016 ¶¶ 96–99). Schmidt discloses that Quake is a 3D game
`application that renders 3D graphics (Ex. 1004, 44–45), and as Petitioner
`points out, Schmidt further discloses that that “3-D graphics performance is
`directly related to the speed of the server processor,” teaching that Quake’s
`3D graphics rendering depends directly on the server processor as well. Pet.
`Reply 21 (citing Ex. 1004, 44; Ex. 1042, 124:18–125:5; Ex. 1035 ¶ 72).
`Schmidt therefore teaches “an application, running on a server, which
`generates 3-dimensional graphics accordingly.” Based on the entirety of the
`record, we find that Petitioner has shown by a preponderance of the evidence
`that the asserted prior art teaches this limitation.
`c) “receiving, from said server, said 3-dimensional graphics in
`the form of a compressed stream of images;”
`Petitioner argues that the combination of Schmidt and Keslin teaches
`or suggests this limitation. Pet. 33, 59 (citing Ex. 1002 ¶¶ 70, 155).
`Petitioner contends that Schmidt’s client receives compressed frames
`as a “compressed stream of images.” Pet. 35. Petitioner asserts that a
`person of ordinary skill in the art would have understood receiving a “stream
`of images” to refer to receiving a sequence of image data, such as a sequence
`of image frames. Id. (citing Ex. 1002 ¶ 74). Petitioner further asserts that a
`person of ordinary skill in the art would also have understood that the image
`frames in Quake are streamed because Schmidt equates Quake with
`“streaming video.” Id. at 35–36 (citing Ex. 1004, Abstract, 34, 46; Ex. 1002
`¶ 75). Petitioner argues that Schmidt discloses that Quake images are
`
`22
`
`

`

`IPR2020-01248
`Patent 8,667,093 B2
`streamed one frame at a time to client devices when it describes how the
`server renders each frame. Id. at 36 (citing Ex. 1004, 45; Ex. 1007, 21;
`Ex. 1002 ¶ 76).
`Next, Petitioner relies on Keslin as teaching a “compressed stream of
`images” because Keslin discloses an application residing on a server that
`renders graphics and compresses the rendered image data before sending the
`image data to a client. Pet. 60–61 (citing Ex. 1005, 3:17–19).
`Petitioner’s annotated version of Figure 2 of Keslin is reproduced
`below.
`
`
`Petitioner’s annotations t

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