`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