throbber
Trials@uspto.gov
`571-272-7822
`
`
` Paper 69
`
`Entered: July 24, 2017
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`
`MICROSOFT CORPORATION,
`Petitioner,
`
`v.
`
`BRADIUM TECHNOLOGIES LLC,
`Patent Owner.
`____________
`
`Case IPR2016-00448
`Patent 7,908,343 B2
` ____________
`
`
`
`Before BRYAN F. MOORE, BRIAN J. McNAMARA, and MINN CHUNG,
`Administrative Patent Judges.
`
`McNAMARA, Administrative Patent Judge.
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and
` 37C.F.R. § 42.73
`
`
`

`

`IPR2016-00448
`Patent 7,908,343 B2
`
`
`
`
`BACKGROUND
`On July 25, 2016, we instituted an inter partes review of claims 1–20
`(the “challenged claims”) of U. S. Patent No. 7,908,343 B2 (“the ’343
`Patent”). Paper 9 (“Dec. to Inst.”). Patent Owner filed a Confidential
`Corrected Patent Owner Response (Paper 20, “PO Resp.”) and a public
`version (Paper 21) and a Motion to Seal (Paper 19), Petitioner filed a
`Petitioner Reply (Paper 34, “Pet. Reply”). Petitioner and Patent Owner both
`filed Motions to Exclude (Papers 45 and 47, respectively) and corresponding
`oppositions (Papers 49 and 47, respectively) and replies (Papers 55 and 58
`(confidential) and 59 (public), respectively). Patent Owner also filed a
`Motion to Seal its Opposition to Petitioner’s Motion to Exclude. Paper 52.
`Transcripts of a combined oral hearing in this proceeding and IPR2016-
`00449 held on April 18, 2017 (Paper 80, “Hrg. Tr.” (public); Paper 81,
`“Confidential Hrg. Tr.” (confidential)) have been entered into the record.
`We have jurisdiction under 35 U.S.C. § 6. This Final Written
`Decision is issued pursuant to 35 U.S.C. §318(a). We base our decision on
`the preponderance of the evidence. 35 U.S.C. § 316(e); 37 C.F.R. § 42.1(d).
`Having reviewed the arguments of the parties and the supporting
`evidence, we conclude that Petitioner has demonstrated by a preponderance
`of the evidence that the challenged claims are unpatentable.
`
`
`THE ’343 PATENT (EXHIBIT 1001)
`In the ’343 Patent, large scale images are retrieved over network
`communication channels for display on client devices by selecting an update
`image parcel relative to an operator controlled image viewpoint to display on
`the client device. Ex. 1001, Abstract; col. 3, ll. 44–48. A request for an
`
`
`
`2
`
`

`

`
`
`IPR2016-00448
`Patent 7,908,343 B2
`
`update image parcel is associated with a request queue for subsequent
`issuance over a communication channel. Id. at col. 3, ll. 48–51. The update
`image parcel is received in one or more data packets on the communications
`channel and is displayed as a discrete portion of the predetermined image.
`Id. at col. 3, ll. 51–57. The update image parcel optimally has a fixed pixel
`array size and may be constrained to a resolution equal to or less than the
`display device resolution. Id.
`The system described in the ’343 Patent has a network image server
`and a client system where a user can input navigational commands to adjust
`a 3D viewing frustum for the image displayed on the client system. Id. at
`col. 5, ll. 24–53. Retrieval of large-scale or high-resolution images is
`achieved by selecting, requesting, and receiving update image parcels
`relative to an operator or user controlled image viewpoint. Id. at col. 3, ll.
`44–48. When the viewing frustum is changed by user navigation
`commands, a control block in the client device determines the priority of the
`image parcels to be requested from the server “to support the progressive
`rendering of the displayed image,” and the image parcel requests are placed
`in a request queue to be issued in priority order. Id. at col. 7, ll. 8–25.
`On the server side, high-resolution source image data is pre-processed
`by the image server to create a series of derivative images of progressively
`lower resolution. Id. at col. 6, ll. 1–6. Figure 2 of the ’343 patent is
`reproduced below.
`
`
`
`
`3
`
`
`
`

`

`IPR2016-00448
`Patent 7,908,343 B2
`
`
`
`
`
`
`
`
`Figure 2 depicts preparation of pre-processed image parcels at the
`network image server. See id. at col. 4, ll. 54–57; col. 5, ll. 60–62; col. 6, ll.
`7–10. As illustrated in Figure 2, source image data 32 is pre-processed to
`obtain a series K1-N of derivative images of progressively lower image
`resolution. Id. at col. 6, ll. 4–6. Initially, the source image data—i.e., the
`series image K0—is subdivided into a regular array of image parcels of a
`fixed byte size, e.g., 8K bytes. Id. at col. 6, ll. 6–11. In an embodiment, the
`resolution of a particular image in the series is related to the predecessor
`image by a factor of four while, at the same time, the array subdivision is
`also related by a factor of four, such that each image parcel of the series
`images has the same fixed byte size, e.g., 8K bytes. Id. at col. 6, ll. 11–16.
`In another embodiment, the image parcels are compressed by a fixed ratio—
`for example, the 8K byte parcels are compressed by a 4-to-1 compression
`ratio such that each image parcel has a fixed 2K byte size. Id. at col. 6,
`
`
`
`4
`
`

`

`IPR2016-00448
`Patent 7,908,343 B2
`
`
`ll. 17–22. The image parcels are stored in a file of defined configuration,
`such that any parcel can be located by specification of a KD, X, Y value,
`representing the image set resolution index D and the corresponding image
`array coordinate. Id. at col. 6, ll. 23–26. The TCP/IP protocol is used to
`deliver image parcels, e.g., 2K-byte compressed image parcels, to the
`clients. Id. at col. 7, ll. 28–29, 35–37. For preferred embodiments, where
`network bandwidth is limited, entire image parcels preferably are delivered
`in corresponding data packets. Id. at col. 7, ll. 29–32. This allows each
`image parcel to fit into a single network data packet, which improves data
`delivery and avoids the transmission latency and processing overhead of
`managing image parcel data broken up over multiple network data packets.
`Id. at col. 7, ll. 32–35.
`
` ILLUSTRATIVE CLAIM
`Claim 1, which is drawn to a method is illustrative:
`
`1. A method of retrieving large-scale images over
`network communications channels for display on a
`limited communication bandwidth computer device, said
`method comprising:
` issuing, from a limited communication bandwidth
`computer device to a remote computer, a request for
`an update data parcel wherein the update data parcel is
`selected based on an operator controlled image
`viewpoint on the computer device relative to a
`predetermined image and the update data parcel
`contains data that is used to generate a display on the
`limited communication bandwidth computer device;
` processing, on the remote computer, source image data
`to obtain a series K1-N of derivative images of
`progressively lower image resolution and wherein
`series image K0 being subdivided into a regular array
`wherein each resulting image parcel of the array has a
`
`
`
`5
`
`

`

`
`
`predetermined pixel resolution wherein image data
`has a color or bit per pixel depth representing a data
`parcel size of a predetermined number of bytes,
`resolution of the series K1-N of derivative images being
`related to that of the source image data or predecessor
`image in the series by a factor of two, and said array
`subdivision being related by a factor of two such that
`each image parcel being of a fixed byte size, wherein
`the processing further comprises compressing each
`data parcel and storing each data parcel on the remote
`computer in a file of defined configuration such that a
`data parcel can be located by specification of a KD, X,
`Y value that represents the data set resolution index D
`and corresponding image array coordinate;
` receiving said update data parcel from the data parcel
`stored in the remote computer over a communications
`channel; and
` displaying on the limited communication bandwidth
`computer device using the update data parcel that is a
`part of said predetermined image, an image wherein
`said update data parcel uniquely forms a discrete
`portion of said predetermined image.
`
`IPR2016-00448
`Patent 7,908,343 B2
`
`
`
`
`GROUND OF INSTITUTION
`In our Decision to Institute, we instituted trial on the following
`challenge to patentability:
`Claims 1–20 as obvious under 35 U.S.C. § 103(a) over Reddy1 in
`view of Hornbacker.2 Dec. to Inst. 44–45.
`
`
`
`1 Ex. 1004, M. Reddy, Y. Leclerc, L. Iverson, N. Bletter, TerraVision II:
`Visualizing Massive Terrain Databases in VRML, IEEE Computer Graphics
`and Applications, Vol. 19, No. 2, 30–38, IEEE Computer Society,
`March/April 1999 (“Reddy”).
`2 Ex. 1003, WO 99/41675 (Aug. 19, 1999) (“Hornbacker”).
`6
`
`
`
`

`

`IPR2016-00448
`Patent 7,908,343 B2
`
`
`
`
`CLAIM CONSTRUCTION
`In our Decision to Institute, we applied the ordinary and customary
`meaning to the terms not construed. Dec. to Inst. 11–12. We determined
`that the term “mesh” in claims 13 and 20 required no further construction.
`Id. at 12. Consistent with our Decision in Microsoft Corp. v. Bradium Tech.
`LLC, Case IPR2015-01434, slip op. at 9 (PTAB Dec. 23, 2015) (Paper 15,
`Decision Denying Institution), which also involved the ’343 Patent, in our
`Decision to Institute in this proceeding, we construed the term “data parcel”
`to mean data that corresponds to an element of a source image array, as the
`broadest reasonable interpretation of that term. Dec. to Inst. 11. Neither
`party proposed constructions for any other claim terms. Id. at 12.
`In the Patent Owner Response, Patent Owner proposes that for the
`term “image parcel” we adopt our construction of that term from related
`case, Microsoft Corp. v. Bradium Tech. LLC, Case IPR2015-01432, slip op.
`at 10 (PTAB Dec. 23, 2015) (Paper 15, Decision to Institute) as “an element
`of an image array, with the image parcel being specified by the X and Y
`position in the image array coordinates and an image set resolution index.”
`PO Resp. 9. Petitioner does not oppose this construction and Patent Owner’s
`proposed construction is consistent with the usage of the term in the ’343
`Patent. Therefore, we apply Patent Owner’s proposed construction in this
`proceeding.
`Limited bandwidth communications channel
`Patent Owner further proposes that we construe the term “limited
`bandwidth communications channel” to mean “a wireless or narrowband
`communications channel.” Id. Patent Owner states that a person of ordinary
`skill would have understood that a limited bandwidth communications
`
`
`
`7
`
`

`

`IPR2016-00448
`Patent 7,908,343 B2
`
`
`channel refers to the communications channel itself, not the device receiving
`the data parcels. Id. Acknowledging that the term is not defined in the
`Specification of the ’343 Patent, Patent Owner argues that the Specification
`indicates that the inventors considered narrowband and wireless
`communication channels as the limited bandwidth channels. Id. at 10 (citing
`Ex. 1001, col. 1, ll. 25–30). Patent Owner contends that wireless networks
`are a form of limited bandwidth communications channel as disclosed in the
`’343 Patent, which contemplates performance on wireless devices in
`describing its preferred embodiment of 4 concurrent threads. Id. at 10–11
`(citing Ex. 1001, col. 3, ll. 6–9, col. 7, ll. 64–67).
`Petitioner notes that both parties’ experts agree that another way to
`say “limited bandwidth” is to use the term “narrowband.” Pet. Reply 1.
`Petitioner further notes that the ’343 Patent Specification does not state that
`limited bandwidth communication channels must be wireless, just that
`wireless conditions may result in limited bandwidth. Id. (citing Ex. 1001,
`col. 3, ll. 6–9; Ex. 1016, Declaration of Dr. William R. Michalson In
`Support Of Petitioner’s Reply (“Michalson Reply Decl.”) ¶¶ 19– 20).
`Petitioner further notes the deposition testimony of inventor Isaac Levanon
`that limited bandwidth channels can be limited by the amount of users. Id.
`at 2 (citing Ex. 1019 (“Levanon Test.”) at 40:18–41:10).
`The term “limited bandwidth communications channel” is not limited
`to a wireless channel, nor does it imply the cause of the limited bandwidth.
`Thus, the term “limited bandwidth communications channel” requires no
`special construction. We apply its ordinary meaning, i.e., a communications
`channel whose bandwidth is limited.
`
`
`
`
`8
`
`

`

`IPR2016-00448
`Patent 7,908,343 B2
`
`
`
`
`Limited Communication Bandwidth Computer Device
`Patent Owner proposes that we construe the term “limited
`communication bandwidth computer device” to mean “a small client for
`example, smaller, typically dedicated function devices often linked through
`wireless network connections, such as PDAs, smartphones, and automobile
`navigation systems.” PO Resp. 12 (citing Ex. 1001, col. 5, ll. 31–34, Ex.
`2003, Declaration of Dr. Peggy Agouris (“Agouris Decl.”) ¶¶ 37–43).
`Patent Owner contends that the ’343 Patent supports this proposed
`construction because it describes a number of preferred embodiments whose
`goal is to provide a client system viable on small clients, i.e., a device
`constrained to very limited network bandwidths either through direct
`technological constraints (a limited bandwidth communications channel, as
`Patent Owner proposes construing that term) or through indirect constraints
`imposed on relatively high-bandwidth channels by high concurrent user
`loads. Id. at 12–13.
`Petitioner contends that the Specification’s identification of a need for
`a system that supports small clients and efficiently utilizes low to very low
`bandwidth connections does not support Patent Owner’s attempt to limit the
`term “limited communication bandwidth computer device” based on
`processing power or device size. Pet. Reply 2. According to Petitioner, the
`’343 Patent describes problems with computational requirements of prior art
`transmission methods separately from those of limited network bandwidths
`and a person of ordinary skill would not conflate processing power or device
`size with bandwidth. Id.
`The Specification characterizes mobile computing devices, such as
`smart phones and personal digital assistants (PDAs) as small clients and
`
`
`
`9
`
`

`

`
`
`IPR2016-00448
`Patent 7,908,343 B2
`
`states that such small clients typically have restricted performance
`processors with limited memory that cannot support extensive graphics
`abstraction layers and are insufficient for conventional client based
`visualization systems. Ex. 1001, col. 2, ll. 45–53; col. 2, l. 59–col. 3, l. 6.
`The Specification does not connect directly these restricted performance
`parameters with a computer device having a limited communication
`bandwidth. The Specification also states that “small clients are generally
`constrained to generally to very limited network bandwidths particularly
`when operating under wireless conditions,” noting that such conditions “may
`exist due to either the direct technological constraints dictated by the use of a
`low bandwidth data channel or indirect constraints imposed on relatively
`high-bandwidth channels by high concurrent user loads.” Id. at col. 3, ll. 7–
`19. This portion of the Specification concerns communication channel and
`network issues, rather than the computing device. Thus, we agree with
`Petitioner that Patent Owner’s proposed construction conflates
`communication channel and computer device issues, and consequently
`decline to adopt Patent Owner’s proposed construction. Instead, we apply
`the plain and ordinary meaning and construe this term to refer to a
`communications device that itself has a limited communication bandwidth.
`
`LEVEL OF ORDINARY SKILL IN THE ART
`The person of ordinary skill in the art is a hypothetical person who is
`presumed to have known the relevant art at the time of the invention. In re
`GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995). In determining the level of
`one with ordinary skill in the art, various factors may be considered,
`including the types of problems encountered in the art, prior art solutions to
`those problems, the sophistication of the technology, rapidity with which
`
`
`
`10
`
`

`

`IPR2016-00448
`Patent 7,908,343 B2
`
`
`innovations are made, and educational level of active workers in the field.
`Id. In a given case, one or more factors may predominate. Id. In addition,
`we are guided by the level of ordinary skill in the art reflected by the prior
`art of record. See Okajima v. Bourdeau, 261 F.3d. 1350, 1355 (Fed. Cir.
`2001).
`Relying upon the Declaration of Dr. William R. Michalson
`(Ex. 1005, “Michalson Decl.”), Petitioner asserts that, at the time of the
`priority date of the ’343 Patent, a person of ordinary skill in the art for the
`technology disclosed in the ’343 Patent would have had a Master of Science
`or equivalent degree in electrical engineering or computer science, or
`alternatively a Bachelor of Science or equivalent degree in electrical
`engineering or computer science, with at least 5 years of experience in a
`technical field related to geographic information system or the transmission
`of digital image data over a computer network. Pet. 10 (citing Ex. 1005
`¶¶ 27–31).
`Patent Owner cites the Declaration of Dr. Peggy Agouris (Ex. 2003,
`“Agouris Decl.”) and asserts that a person of ordinary skill in the art would
`have had at least a Bachelor of Science or equivalent degree in electrical
`engineering or computer science. PO Resp. 8 (citing Ex. 2003 ¶¶ 17–18). In
`addition, Patent Owner argues that the education levels of the listed
`inventors for the ’343 Patent indicate that no master’s degree is required. Id.
`Patent Owner’s argument against a master’s degree is unpersuasive
`because “[t]he actual inventor’s skill is irrelevant” to the level of skill of a
`hypothetical person of ordinary skill in the art. Standard Oil Co. v. Am.
`Cyanamid Co., 774 F.2d 448, 454 (Fed. Cir. 1985). Nonetheless, the
`parties’ definitions are not necessarily inconsistent because Dr. Agouris
`
`
`
`11
`
`

`

`IPR2016-00448
`Patent 7,908,343 B2
`
`
`opines that a person of ordinary skill in the art at the time of the invention
`would have had at least two years of experience in image and graphics
`processing including developing, designing, or programming client-server
`software for computer networked environments beyond a bachelor’s degree.
`Ex. 2003 ¶ 17. First, we do not perceive any meaningful difference between
`the parties’ definitions of the technical field of the required experience.
`Second, the parties do not argue, nor do we find, that the difference between
`two and five years of experience by a person of ordinary skill in the art
`would impact the obviousness inquiry in any way in this proceeding. See
`Ex. 2003, Agouris Decl., ¶ 18 (stating that Dr. Agouris’s proffered opinions
`would not change even if Petitioner’s definition of the level of ordinary skill
`in the art is applied). Based on the foregoing, we determine that a person of
`ordinary skill in the art at the time of the invention of the ’343 Patent would
`have had a Bachelor of Science or equivalent degree in electrical
`engineering or computer science as well as two to five years of experience in
`a technical field related to geographic information system or the
`transmission of digital image data over a computer network.
`
`ANALYSIS OF PRIOR ART CHALLENGES
`The sole ground on which we instituted inter partes review is
`Petitioner’s challenge to clams 1–20 as obvious under 35 U.S.C. § 103 over
`the combination of Reddy and Hornbacker. A patent 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 the invention was made to a person having
`ordinary skill in the art to which said subject matter pertains. KSR Int’l Co.
`v. Teleflex Inc., 550 U.S. 398, 406 (2007). The test for obviousness is
`
`
`
`12
`
`

`

`
`
`IPR2016-00448
`Patent 7,908,343 B2
`
`whether the combination of references, taken as a whole, would have
`suggested the patentees’ invention to a person having ordinary skill in the
`art. In re Merck & Co., Inc., 800 F.2d 1091, 1097 (Fed. Cir. 1986).
`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).
`Whether a patent claiming the combination of prior art elements
`would have been obvious is determined by whether the improvement is more
`than the predictable use of prior art elements according to their established
`functions. KSR, 550 U.S. at 417. To reach this conclusion, however,
`requires more than a mere showing that the prior art includes separate
`references covering each separate limitation in a claim under examination.
`Unigene Labs., Inc. v. Apotex, Inc., 655 F.3d 1352, 1360 (Fed. Cir. 2011).
`Obviousness requires the additional showing that a person of ordinary skill
`at the time of the invention would have selected and combined those prior
`art elements in the normal course of research and development to yield the
`claimed invention. Id. However, a precise teaching directed to the specific
`subject matter of a challenged claim is not necessary to establish
`obviousness. KSR, 550 U.S. at 418. As the Supreme Court recognized, in
`many cases a person of ordinary skill “will be able to fit the teachings of
`multiple patents together like pieces of a puzzle,” recognizing that a person
`of ordinary skill “is also a person of ordinary creativity, not an automaton.”
`Id. at 420–21. Against this general background, we consider the references,
`other evidence, and arguments of the parties.
`
`
`
`13
`
`

`

`IPR2016-00448
`Patent 7,908,343 B2
`
`
`
`
`Introduction
`Petitioner cites Reddy as teaching a system for retrieving massive
`terrain data sets using a client, such as a personal computer (PC) that can be
`implemented with a plug-in for a standard browser, i.e., the VRML browser
`plug-in. Pet. 18, 26. According to Petitioner, Reddy allows the user to
`browse on-line geographic information in standard VRML, thereby
`providing compatibility with different sources, and enables access for a
`standard personal computer, such as a laptop over the worldwide web
`(WWW), instead of a specialized high-speed network. Pet. 15 (citing
`Ex. 1004 ¶¶ 9, 31, 39, 48).
`Petitioner cites Hornbacker as using graphical web browsers on client
`systems to view large images divided into tiles. Pet. 27 (citing Ex. 1003,
`Abstract, p. 6, l. 20–p. 7, l. 1; p. 13, l. 28–p. 14, l. 11, p. 14, ll. 26–28).
`According to Petitioner, like Reddy, Hornbacker addresses similar technical
`issues as those addressed in the ’343 Patent, i.e., network and system
`performance problems in accessing large image files from a network file
`server. Id. at 18. The ’343 Patent states, “As well recognized problem with
`such conventional systems could be that full resolution image presentation
`may be subject to inherent transfer latency of the network.” Ex. 1001, col. 1,
`ll. 48–51. Petitioner cites Hornbacker as teaching methods of dividing large
`data sets into tiles, compressing those tiles and requesting the appropriate
`tiles over a network. Pet. 14.
`Patent Owner contends that Reddy fails to disclose several of the
`elements recited in the claims, including the “limited communications
`bandwidth computer device” recited in all the claims, and that a person of
`ordinary skill would not select Reddy when considering a bandwidth limited
`
`
`
`14
`
`

`

`
`
`IPR2016-00448
`Patent 7,908,343 B2
`
`situation because Reddy discloses a high bandwidth communications
`channel and a device requiring extensive software to be loaded onto the user
`computer. PO Resp. 18. Patent Owner contends that Hornbacker does not
`disclose storing each data parcel on the remote computer in a file of defined
`configuration such that a data parcel can be located by specifying a KD, X, Y
`value, as recited in all the claims. Id. at 17–18. Patent Owner further
`contends that neither Reddy nor Hornbacker discloses the prioritizations
`elements of claims 10 and 11. Id.
`Patent Owner contends that a person of ordinary skill would not have
`been motivated to cure Reddy’s deficiencies by combining its teachings with
`those of Hornbacker because (i) Hornbacker is directed to document
`processing for GIS applications having very different technical constraints
`than those of Reddy, and (ii) Reddy uses specialized client-based image
`software to pre-compute tiles and share them among clients with the goal of
`real-time “fly over” system performance, so that low resolution tiles can
`reside in the memory of a client and be accessed as necessary, but
`Hornbacker avoids such client based software by using HTTP requests to a
`server that creates tiles on demand in a server based, computationally
`intensive process unsuitable for real-time processing. PO Resp. 18–19.
`Patent Owner further contends that objective considerations
`demonstrate that the claimed subject matter is not obvious under 35 U.S.C.
`§ 103. PO Resp. 52–60.
`Our Decision to Institute analyzed Petitioner’s challenges and the
`Patent Owner Preliminary Response in the context of claim elements
`designated by Petitioner (e.g., 1.A, 1.B, 13.A, 13.B). For consistency, we
`use the same claim element designations in this Decision. Independent
`
`
`
`15
`
`

`

`IPR2016-00448
`Patent 7,908,343 B2
`
`
`claim 1 and claims 2–12 that depend from claim 1 are drawn to a method.
`Independent claim 13 and claims 14–20 that depend from claim 13 are
`drawn to an apparatus.
`Patent Owner disputes that Reddy and Hornbacker disclose certain
`claim elements reciting (i) a limited bandwidth communication channel and
`a limited communication bandwidth computer device in all claims (PO Resp.
`21–26), (ii) selection of data parcels for progressive resolution enhancement
`in claims 13.F, 13.G, 13.H and dependent claim 14–20 (id. at 26–28), (iii)
`prioritization of requests for image parcels recited in dependent claim 15 and
`the use of a prioritization value recited in dependent claims 10 and 11 (id. at
`28–35), and (iv) the “efficient data structure recited in claim 1.D, 1.J, 13. J,
`and 13.P and all dependent claims (id. at 35–43). Our Decision to Institute
`includes a detailed analysis of each claim element in the context of the
`Reddy and Hornbacker references. Dec. to Inst. 23–44. Mindful that at this
`stage of the proceeding the burden of proof is on the Petitioner by a
`preponderance of the evidence, below we address the specific arguments
`raised by Petitioner and Patent Owner as to whether the claims are
`unpatentable.
`Reddy
`Reddy “aim[s] to enable visualization of near photorealistic 3D
`models of terrain that can be on the order of hundreds of gigabytes,”
`allowing users to select dynamically particular sets of geo-referenced data.
`Ex. 1004 ¶¶ 2, 10. Reddy implements its functionality in a standard VRML
`browser for downloading over the World Wide Web, using Java scripting to
`extend VRML’s base functionality and the External Authoring Interface to
`provide application-specific management of a virtual geographic
`
`
`
`16
`
`

`

`
`
`IPR2016-00448
`Patent 7,908,343 B2
`
`environment. Id. at ¶¶ 9, 10. Reddy also discloses a custom terrain
`visualization package (TerraVision II) that can browse standard VRML data
`structures. Id. at ¶ 9. Although TerraVision II is not required to view the
`content, its specialized browser level optimizations “offer increased
`efficiency and seamless interaction with the terrain data.” Id. at ¶¶ 9, 48.
`Recognizing that the time to download and render a terrain model
`would prohibit real time interaction, Reddy employs level of detain (LOD)
`techniques to change a model’s complexity based on selection criteria, such
`as distance from the viewpoint or projected screen size. Id. at ¶¶ 12–13.
`Reddy uses a tiled pyramid representation to provide a view dependent
`technique that can vary the degree of simplification relative to the current
`viewpoint using a hierarchical data structure (such as a quad tree), without
`requiring access to the entire high resolution version of the data set (as that
`would limit viewing to data sets that can fit within a user’s local storage).
`Id. at ¶ 14. Reddy’s pyramid model provides a multiresolution hierarchy for
`a data set in which an original image, e.g., a 1024 x 1024 image, can be
`down sampled at lower resolutions, e.g., 512 x 512 pixels, 256 x 256 pixels,
`and 128 x 128 pixels. Id. at ¶ 15. Each image is then segmented into
`rectangular tiles, each tile having the same pixel dimensions. Id. Using this
`approach, a tile at a given pyramid level maps onto four tiles on the next
`higher level, such that at each higher resolution area, the tiles cover half the
`geographic area of the previous level. Id. Reddy states that its tiled image
`representation “optimize[s] the amount of data transferred over the network”
`because “we need only fetch and display for the region that the user is
`viewing, and only at a sufficient resolution for the user’s viewpoint.” Id. at
`¶ 17.
`
`
`
`17
`
`

`

`IPR2016-00448
`Patent 7,908,343 B2
`
`
`
`Reddy employs terrain files (that describe actual elevation and image
`texture data), feature files (that describe objects such as building and roads
`in a geographic areas), tree files (that implement part of the multiresolution
`hierarchy) and geotile files (that contain links to all data within a single tile).
`Id. at ¶¶ 18, 19, 22. To implement the multi-resolution hierarchy, a tree file
`initially loads a single geotile. Id. at ¶ 19. When a ProximitySensor
`recognizes a user’s approach, the geotile is replaced with four higher
`resolution tree files that in turn inline geotiles for the four quad tree children,
`using Reddy’s QuadLOD feature (instead of VRML’s Inline node). Id. at
`¶¶ 19, 21. Except for extending the tree for higher resolution, the hierarchy
`of tree files need be generated only one time. Id.
`A user browses terrain data using a standard VRML plug-in for
`Internet browsers, such as Internet Explorer. Ex. 1004, ¶ 31. Reddy
`discloses using a Java applet running in the Internet browser and
`communicating with the VRML plug-in to traverse a scene graph of a loaded
`terrain and modify the switch node settings in each geotile file to select
`different data sets, as well as modified inline nodes that expose the inlined
`VRML file. Id. ¶¶ 31–32. This approach makes it possible to inspect and
`modify any part of the VRML scene. Id. Noting that the three standard
`navigation default types in VRML are walk, examine, and fly, Reddy
`discloses three additional specialized functions to navigate a large
`geographic database: (i) terrain following (to deal with earth curvature), (ii)
`altitude based velocity (to achieve a constant pixel flow across a screen), and
`(iii) active maps (a Java applet that manages a map display using a position-
`changed eventOut of a ProxmitySensor placed around the entire scene to
`
`
`
`18
`
`

`

`IPR2016-00448
`Patent 7,908,343 B2
`
`
`project a 3D geocentric coordinate onto the map, allowing users to ascertain
`their location). Id. at ¶¶ 35–37.
`TerraVision II is a custom VRML browser specifically designed to
`optimize navigation of Reddy’s VRML databases. Id. at ¶ 39. TerraVision
`II has the following advantages over a standard VRML browser: (i) visibility
`culling using a fast quad-tree search of the multiresolution hierarchy (id. at
`¶ 41), (ii) level of detail improvement using projected screen size to decide
`when to reduce terrain detail considering such factors as display size and the
`angle at which the user views the terrain (id. at ¶ 42), (iii) techniques to
`address discontinuities resulting from adjacent tiles of different resolutions
`id. at ¶ 43), (iv) maintenance of a low resolution terrain representation and a
`progressive coarse to fine algorithm to load and display new data, using
`lower resolution tiles if higher resolution data has yet to arrive, providing
`continuous interaction with the scene (id. at ¶ 44), (v) tile caching to reduce
`the need to read and parse data for recently visited regions (id at ¶ 45), and
`(vi)

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