UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`MICROSOFT CORPORATION
`
`Petitioner
`
`v.
`
`BRADIUM TECHNOLOGIES LLC
`
`Patent Owner
`
`CASE IPR2016-01897
`
`Patent No. 9,253,239
`
`DECLARATION OF DR. PEGGY
`AGOURIS IN SUPPORT OF PATENT
`OWNER PRELIMINARY RESPONSE
`
`
`
`
`
`
`
`Exhibit 2003
`Bradium Technologies LLC - patent owner
`Microsoft Corporation - petitioner
`IPR2016-01897
`1
`
`

`
`
`
`TABLE OF CONTENTS
`
`Page
`
`I.
`
`INTRODUCTION .............................................................................................. 1
`
`A. Background and Qualifications .................................................................. 2
`
`B. Materials Considered .................................................................................. 3
`
`C. Person of Ordinary Skill in the Art (“POSA”) ........................................... 4
`
`D. Claim Construction ..................................................................................... 6
`
`1.
`
`2.
`
`3.
`
`“Data Parcel” (Claims 1, 12, 17, 21, 22) ............................................ 6
`
`“Image Parcel” (Claims 1, 25) ............................................................ 7
`
`“Mobile Device” (Claim 23) .............................................................. 9
`
`II. SUMMARY OF OPINION ..............................................................................13
`
`III. MY ANALYSIS OF CLAIMS 1–25 ...............................................................13
`
`A. Summary ................................................................................................... 13
`
`B. Discussion of Reddy, Hornbacker, and Loomans .................................... 18
`
`1. Reddy ................................................................................................ 18
`
`2. Hornbacker ........................................................................................ 19
`
`3. Loomans ............................................................................................ 20
`
`C. The Asserted References Do Not Teach or Suggest All Elements of
`Claims 20 or 24 (Ground 1) and Claim 22 (Ground 2) of the ’239
`Patent ........................................................................................................ 21
`
`1. Neither Reddy nor Hornbacker teaches or suggests
`determining priority of the first request and the second request
`(Claim 20) ......................................................................................... 21
`
`2. Neither Reddy nor Hornbacker teaches or suggests the use of
`two servers (Claim 24) ...................................................................... 24
`
`3. Reddy, Hornbacker, and Loomans do not teach or suggest the
`use of four concurrent threads to request and retrieve update
`data parcels (Claim 22) ..................................................................... 26
`
`D. Reddy Does Not Teach or Suggest the Use of TerraVision II on a
`Mobile Device (Claim 23) ....................................................................... 30
`
`i
`
`2
`
`

`
`
`
`E. A POSA Would Not Have Selected and Combined the Asserted
`References ................................................................................................ 34
`
`1. A POSA would not have selected Reddy ......................................... 34
`
`2. A POSA would not have combined Reddy and Hornbacker ........... 37
`
`3. A POSA would not have combined Reddy or Hornbacker
`with Loomans ................................................................................... 39
`
`4. Hornbacker and Reddy are incompatible ......................................... 40
`
`5. Hornbacker and Loomans are incompatible ..................................... 42
`
`6. Austreng teaches away from the asserted combination of
`Reddy and Hornbacker with Loomans ............................................. 43
`
`IV. Concluding Statement ......................................................................................48
`
`
`
`
`
`ii
`
`3
`
`

`
`
`
`LIST OF APPENDICES
`
`APPENDIX A
`
`Dr. Peggy Agouris Curriculum Vitae
`
`
`
`iii
`
`4
`
`

`
`
`
`I.
`
`INTRODUCTION
`
`1.
`
`I have been retained by counsel for Bradium Technologies LLC
`
`(“Bradium” or “Patent Owner”) as an expert consultant in regards to inter partes
`
`review proceeding IPR2016-01897 for U.S. Patent No. 9,253,239.
`
`2.
`
`In
`
`IPR2016-01897,
`
`I understand
`
`that Petitioner, Microsoft
`
`Corporation (“Microsoft” or “Petitioner”) is challenging the validity of Claims 1
`
`through 25 of the ’239 Patent.
`
`3.
`
`I understand that Microsoft has petitioned for inter partes review on
`
`the following Grounds:
`
`Ground 1: Claims 1–20, 23–25 as obvious under 35 U.S.C. § 103(a) over
`
`Reddy (Ex. 1004) in view of Hornbacker (Ex. 1003).
`
`Ground 2: Claims 21–22 as obvious under 35 U.S.C. § 103(a) over Reddy
`
`in view of Hornbacker and Loomans (Ex. 1014).
`
`4.
`
`I was asked to consider whether the challenged claims of the U.S.
`
`Patent No. 9,253,239 (“the ’239 Patent”) (Ex. 1001), which are Claims 1 through
`
`25, would have been obvious to a person of ordinary skill in the art (“POSA”) as of
`
`the date of the invention.
`
`1
`
`5
`
`

`
`
`
`A. Background and Qualifications
`
`5.
`
`This is a summary of my background and qualifications. I set forth
`
`my background in more detail in my Curriculum Vitae which is attached as
`
`Appendix A.
`
`6.
`
`I am currently Dean of the College of Science at George Mason
`
`University. I am additionally the Director of the Center for Earth Observing &
`
`Space Research at George Mason University. I was previously employed as a
`
`Professor of Geoinformatics at the College of Science at George Mason University.
`
`7.
`
`Prior to my employment at George Mason University, I was an
`
`assistant professor, and then associate professor, at the School of Computing and
`
`Information Science at the University of Maine from 1995 to 2001 and 2001 to
`
`2006 respectively. During my time as associate professor, I was also the Chief
`
`Technology Officer at Milcord Maine, LLC from 2004 to 2006. I served as the
`
`Chair of the department of Geography and Geoinformation Science at George
`
`Mason University from 2008 to 2013 and was the Acting Associate Provost for
`
`Graduate Education at George Mason University from 2012 to 2013.
`
`8.
`
`I have an Engineering Diploma, which I obtained from the National
`
`Technical University of Athens, Greece. I also have a Master of Science degree in
`
`Civil and Environmental Engineering and Geodetic Science and a Doctorate in
`
`Digital Image Processing and Analysis from the Ohio State University.
`
`2
`
`6
`
`

`
`
`
`9.
`
`Based on my academic and industry experience, as set forth more
`
`fully in Appendix A, I am quite familiar with the state of the art in 1999 in
`
`Geographic Information Systems (GIS) and related fields. I was, and continue to
`
`be, actively involved in the field.
`
`B. Materials Considered
`
`10. For time spent in connection with this case, I am being compensated
`
`at my customary rate. My compensation is not dependent upon the outcome of
`
`this petition or any issues involved in or related to the ’239 Patent, and I have
`
`no other financial stake in this matter. I have no financial interest in, or affiliation
`
`with, any of the real parties in interest or the patent owner.
`
`11. The materials I considered include the ’239 Patent, materials
`
`incorporated by reference therein, the prosecution history for the ’239 Patent, the
`
`Petition from Microsoft for inter partes review (Paper No. 2), and the Michalson
`
`Declaration in support of the Petition (Ex. 1005). I also considered the materials
`
`that I refer to and that I cite in this declaration, and, to the extent that I considered
`
`them relevant, the materials provided by Dr. Michalson or the Petitioner.
`
`12.
`
`In addition, I have drawn on my experience and knowledge, as
`
`discussed above and described more fully in my CV, in the areas of image
`
`processing, geographic information systems, interactive computer graphics, and
`
`dynamic visualization, among other areas.
`
`3
`
`7
`
`

`
`
`
`13.
`
`I understand that Bradium considers the date of invention for the ’239
`
`Patent to be October 1999. I understand that Dr. Michalson considered the date of
`
`invention to be December 2000 based on the ’239 patent’s discussion of the
`
`technology background. See Ex. 1005 ¶3.
`
`14. Counsel for Bradium has asked me to assume that the asserted
`
`references, Reddy, Hornbacker, and Loomans, are prior art for the purposes of my
`
`analysis. I have not performed an analysis as to whether any reference is prior art,
`
`but instead I have made this assumption at Counsel’s request. I have further been
`
`asked to consider both asserted dates of invention. My analysis would not change
`
`based on which of these dates I assume.
`
`C.
`
`Person of Ordinary Skill in the Art (“POSA”)
`
`15. The ’239 Patent relates to networked or internet based image
`
`distribution systems, in particular to a system and methods for efficiently selecting
`
`and distributing image parcels through a narrowband or otherwise limited
`
`bandwidth communications channel to support presentation of high-resolution
`
`images subject to dynamic viewing frustums. See Ex. 1001, 1:27–32.
`
`16.
`
`I understand
`
`that
`
`the factors considered
`
`in determining
`
`the
`
`ordinary level of skill in the art include the level of education and experience of
`
`persons working in the field, the types of problems encountered in the field, and
`
`the sophistication of the technology.
`
`4
`
`8
`
`

`
`
`
`17. Based on these factors, in my opinion, a person of ordinary skill in
`
`the art (“POSA”) relating to the technology of the ’239 Patent at the time of the
`
`invention would have been a person with a four-year bachelor’s degree or
`
`equivalent in Electrical Engineering, Computer Engineering, or Computer Science,
`
`as well as at least two years of experience in image and graphics processing
`
`including developing, designing, or programming client-server software for
`
`computer networked environments.
`
`18.
`
`I understand that Dr. Michalson has opined that a POSA should have
`
`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 (“GIS”) or the transmission of
`
`image data over a computer network. (Ex. 1005 ¶31.) My opinions as set forth in
`
`this declaration would not change even if I were to assume Dr. Michalson’s
`
`definition of a POSA is correct.
`
`19. The opinions I express herein are given from the point of view of
`
`a person of ordinary skill in the art, as described above, at the time of the
`
`invention of the ’239 Patent (which I will treat as the latter of the two dates for
`
`consideration). Even if I do not repeat this explicitly, this is the perspective that I
`
`applied in my analysis and in this declaration, unless I indicate otherwise. It is my
`
`5
`
`9
`
`

`
`
`
`opinion that a POSA would not change substantially between October 1999 and
`
`December 2000 for the purposes of my analysis of these asserted prior art
`
`references.
`
`D. Claim Construction
`
`20.
`
`I understand that the claims and specification of a patent must be read
`
`and construed through the eyes of a person of ordinary skill in the art at the time of
`
`the priority date of the claims.
`
`21.
`
`I further understand that the claim construction standard that applies
`
`for the purposes of this proceeding is the broadest reasonable interpretation (BRI)
`
`of the claim language, in light of the specification. I have applied this standard in
`
`claim constructions I have set forth below.
`
`22. Elsewhere in my analysis, except when I state otherwise, I have
`
`applied the ordinary meaning of claim terms as they are used in the specification,
`
`under the BRI standard.
`
`1.
`
` “Data Parcel” (Claims 1, 12, 17, 21, 22)
`
`I understand that the Petitioner has proposed a construction of the term
`
`“Data Parcel” to be “data that corresponds to an element of a source image array,”
`
`Paper 2, p.12, and that Patent Owner agrees with this construction. I have applied
`
`this definition in my analysis.
`
`6
`
`10
`
`

`
`
`
`2.
`
`“Image Parcel” (Claims 1, 25)
`
`23. The claim term “image parcel” is used in two claims of the ’239
`
`Patent. Claim 1 recites in part: (Ex. 1001, 13:4–17 (Elements 1.H–K))
`
`wherein:
`a series of K1-N derivative images of progressively
`lower image resolution comprises the first derivative
`image and the second derivative image, the series of K1-
`N of derivative images resulting from processing the
`source image data, series image K0 being subdivided into
`a regular array wherein each resulting image parcel of the
`array has a predetermined pixel resolution and a
`predetermined color or bit per pixel depth, resolution of
`the series K1-N of derivative images being related to
`resolution of the source image data or predecessor image
`in the series by a factor of two, and the array subdivision
`being related by a factor of two.
`
`Claim 25 recites: (Ex. 1001, 15:21–22)
`
`A method as in claim 1, wherein each image parcel is of
`a fixed byte size.
`
`24.
`
`I understand that the Petitioner has not offered a construction of the
`
`term “image parcel” in this ’239 Patent IPR aside from “plain and ordinary
`
`meaning.” Paper 2, p.12:14–16.
`
`25.
`
`I understand that the Board construed “Image Parcel” in IPR2015–
`
`01432 for the related U.S. Pat. No. 7,139,794, which has a substantially identical
`
`specification to the ’239 patent. IPR2015–01432, Paper 15, p.10 (P.T.A.B. Dec.
`
`23, 2015); see also Ex. 1005 ¶166. The Board construed “Image Parcel” to be “an
`
`element of an image array, with the image parcel being specified by the X and Y
`
`7
`
`11
`
`

`
`
`
`position in the image array coordinates and an image set resolution index.”
`
`IPR2015–01432, Paper 15, p.10. I understand that Patent Owner has proposed this
`
`definition be adopted in this IPR. I have reviewed and I agree with this proposed
`
`construction.
`
`26. Petitioner does not appear to dispute Patent Owner’s proposed
`
`construction, as Petitioner cites to and appears to apply the Board’s construction of
`
`Image Parcel in IPR2015-01432 in the Petition. Paper 2, 37:19–38:1.
`
`27. Support for this construction can be found in the specification, for
`
`example, at Ex. 1001, 6:6–18; 6:25–28, and as set forth below.
`
`28. The ’239 Patent describes source image data as being subdivided into
`
`a regular array, such that each resulting “image parcel” of the array has a pixel
`
`resolution, e.g., 64 by 64 pixel resolution, where the image has a color or bit per
`
`pixel depth of 16 bits, which represents a data parcel size of 8K bytes. Ex. 1001,
`
`6:6–18. Any image parcel can be located by specifying X, Y, and KD, where X
`
`and Y are the image array coordinates and D is the image set resolution index.
`
`Ex. 1001, 6:25–28; see also Petition, p.38 (arguing that Reddy would need to
`
`specify the location and resolution level of the tiles within the view).
`
`8
`
`12
`
`

`
`
`
`3.
`
`“Mobile Device” (Claim 23)
`
`29.
`
`I understand that Petitioner and Dr. Michalson have not offered a
`
`construction of this term aside from “plain and ordinary meaning”. Paper 2,
`
`p.12:14–16; Ex. 1005 ¶100.
`
`30.
`
`I understand that Patent Owner has proposed a BRI claim construction
`
`for the term “mobile device” of “a portable small client such as a mobile phone,
`
`smart phone, or personal digital assistant (PDA) that is constrained to limited
`
`bandwidth.” I have reviewed and I agree with this proposed construction.
`
`31. Support for this construction can be found in the specification, for
`
`example, at Ex. 1001, 2:43–61; 3:10–39; 3:40–51; 4:4–13; 4:4–13; 4:21–29, and as
`
`set forth below.
`
`32. A POSA would have understood Bradium’s proposed construction to
`
`be the broadest reasonable interpretation in light of the specification. A POSA
`
`would have understood the relevant context of the specification to include the need
`
`for “an image visualization system that can support small client systems, place few
`
`requirements on the supporting client hardware and software resources, and
`
`efficiently utilize low to very low bandwidth network connections.” Ex. 1001,
`
`3:36–39 (emphasis added). A POSA would have considered it relevant that the
`
`specification is directed to a method for retrieval of large-scale images under
`
`9
`
`13
`
`

`
`
`
`limited bandwidth conditions that is usable by small client devices. See, e.g., Ex.
`
`1001, 3:10–39; 3:47–51; 4:4–13.
`
`33. A POSA would have understood
`
`that, based on
`
`the patent
`
`specification, the distinction between “mobile device” and “user computer device”
`
`is not directed only to the concept of mobility itself but also to the attributes
`
`associated with mobility.
`
`34. One advantage of the invention is that “image parcel data rendering is
`
`performed without requiring any complex underlying hardware or software display
`
`subsystem,” and the patent explains that the client software of the invention places
`
`“minimal requirements on any underlying embedded or disk operating system and
`
`display drivers” and that “[c]omplex graphics and animation abstraction layers are
`
`not required.” Ex. 1001, 4:21–29. The patent specification also notes that the
`
`invention requires “minimal client processing power and storage capacity,” that
`
`“[c]ompute intensive numerical calculations are minimally required,” and that
`
`client software is “very small” and easily downloaded to “portable devices, such as
`
`PDAs, tablets and webphones.” Ex. 1001, 4:4–13.
`
`35. The background section of
`
`the
`
`’239 patent explains
`
`that
`
`implementation of “conventional image visualization systems” is “generally
`
`unworkable” for small clients, and that conventional approaches “effectively
`
`presume that client systems have an excess of computing performance, memory
`
`10
`
`14
`
`

`
`
`
`and storage.” Ex. 1001, 3:40–49. The specification further notes that “[s]uch
`
`systems are not readily capable, if at all, of performing complex, compute-
`
`intensive Fourier or wavelet transforms, particularly within a highly restricted
`
`memory address space.” Ex. 1001, 2:58–61.
`
`36.
`
`It is my understanding that U.S. Provisional Application No.
`
`60/258,489 (the “’489 Application”) is incorporated by reference into the ’239
`
`Patent specification. Ex. 1001, 1:7–24. The ’489 Application teaches that a
`
`cellular phone or PDA will have a small processor and low memory. E.g., Ex.
`
`2004, 2:5–9 (“Currently, with regard to conventional client systems, a larger image
`
`array, such as 128xl28, is too large to be fully placed within the level-1 cache of
`
`many of the smaller conventional current processors, such as used by personal
`
`digital assistants (PDAs) and cellular phones.”). The ’489 Application further
`
`explains that “client systems are contemplated to be conventional personal
`
`computer systems and, in particular, mobile, cellular, embedded, and handheld
`
`computer systems, such as personal digital assistants (PDAs) and internet-capable
`
`digital phones, with
`
`relatively
`
`limited
`
`to highly constrained network
`
`communications capabilities.” E.g., Ex. 2004, 2:6–11.
`
`37. The ’239 patent also states that a “small client” is generally
`
`constrained
`
`to “very
`
`limited network bandwidths” either
`
`through “direct
`
`technological constraints” (a limited bandwidth communications channel as
`
`11
`
`15
`
`

`
`
`
`explained above) or through “indirect constraints imposed on relatively high-
`
`bandwidth channels by high concurrent user loads.” Ex. 1001, 3:10–19. An
`
`example of “high concurrent user load” would be a cellular tower serving multiple
`
`devices simultaneously. Cellular connected PDAs and webphones are examples of
`
`small clients that are frequently constrained by limited bandwidth conditions (Ex.
`
`1001, 3:17–19). The conventionally realizable maximum network transmission
`
`bandwidth for such small devices at the time of the ’239 patent “may range from
`
`below one kilobit per second to several tens of kilobits per second.” Ex. 1001,
`
`3:17–22.
`
`38. The specification describes a number of preferred embodiments of
`
`the ’239 patent’s invention, whose goal I understand based on the specification is
`
`to provide a client system viable on small clients. See, e.g., Ex. 1001, 3:35–39. “A
`
`mobile computing device such as mobile phone, smart phone, and or personal
`
`digital assistant (PDA) is a characteristic small client. Embedded, low-cost kiosk
`
`and or automobile navigation systems are other typical examples.” Ex. 1001,
`
`2:53–58. “The client software system is very small and easily downloaded to
`
`conventional computer systems or embedded in conventional dedicated function
`
`devices, including portable devices, such as PDAs and webphones.” Ex. 1001,
`
`4:9–12.
`
`12
`
`16
`
`

`
`
`
`39. Based on the disclosures of the patent specification, including the
`
`provisional applications incorporated by reference into the specification, a POSA
`
`would have understood the broadest reasonable interpretation of “mobile device”
`
`to be “a portable small client such as a mobile phone, smart phone, or personal
`
`digital assistant (PDA) that is constrained to limited bandwidth.”
`
`II.
`
`SUMMARY OF OPINION
`
`40.
`
`In this Section I present a summary of my opinions. The full
`
`statement of my opinions and the bases for my opinions are contained in the
`
`appropriate sections of my declaration. I give this summary, however, for the
`
`convenience of the reader.
`
`41. For the reasons set forth in this declaration, and based on my analysis
`
`of the ’239 Patent, my knowledge and experience, my understanding of the state of
`
`the art in 1999 (and 2000), my analysis of the Petition and accompanying materials
`
`and of the Board’s institution decision, it is my opinion that the challenged claims
`
`(1–25) would not have been obvious to a POSA as of the date of the invention.
`
`III. MY ANALYSIS OF CLAIMS 1–25
`
`A.
`
`42.
`
`Summary
`
`It is my opinion that the asserted claims would not have been obvious
`
`to a POSA at the time of the invention, because the asserted combination of Reddy,
`
`Hornbacker, and Loomans does not teach or suggest the elements of certain claims,
`
`13
`
`17
`
`

`
`
`
`and because a POSA would not have combined the asserted references to achieve
`
`the claimed invention.
`
`43. Regarding the Petitioner’s asserted Ground 1, it is my opinion that the
`
`asserted prior art combination of Reddy and Hornbacker does not teach or suggest
`
`at all the elements of claims 20 or 24.
`
`44. Regarding the Petitioner’s asserted Ground 2, it is my opinion that the
`
`asserted prior art combination of Reddy, Hornbacker, and Loomans does not teach
`
`or suggest at all the elements of claim 22.
`
`45. The specific claim elements not taught or disclosed by the asserted
`
`prior art are as follows:
`
`46. None of the asserted prior art references teach the ’239 patent’s use of
`
`Priority: “A method as in claim 1, further comprising a step for determining
`
`priority of the first request and the second request.” (Claim 20).
`
`47. None of the asserted prior art references teach the ’239 patent’s use of
`
`Four Concurrent Threads: “. . . the steps of issuing the first request and
`
`receiving the first update data parcel are part of a first thread; the steps of issuing
`
`the second request and receiving the second update data parcel are part of a second
`
`thread; the steps of issuing the third request and receiving the third update data
`
`parcel are part of a third thread; the steps of issuing the fourth request and
`
`receiving the fourth update data parcel are part of a fourth thread; and the first
`
`14
`
`18
`
`

`
`
`
`thread, the second thread, the third thread, and the fourth thread are executed at
`
`least in part concurrently.” (Claim 22).
`
`48. None of the asserted prior art references teach the ’239 patent’s use of
`
`Two Servers: “A method as in claim 1, wherein the one or more servers comprise
`
`at least two servers.” (Claim 24).
`
`49.
`
`In addition, a POSA would not have combined the asserted
`
`combination of references to arrive at the patented invention.
`
`50. The Petitioner relies on Reddy as a primary reference, and attempts to
`
`add Hornbacker and (for claims 21–22) Loomans to cure the deficiencies of Reddy.
`
`For all asserted claims, a POSA would not have combined Hornbacker with Reddy
`
`to cure the deficiencies in Reddy for at least two reasons.
`
`51. First, a POSA would not have considered a document-processing
`
`reference such as Hornbacker for GIS applications, because document source
`
`material imposes very different technical constraints than does GIS data. See
`
`Section III.E.2.
`
`52. Second, Hornbacker and Reddy
`
`take starkly different and
`
`incompatible technical approaches. Reddy is directed to specialized client-based
`
`image viewing software in which tiles are pre-computed and shared among all
`
`clients with the goal of real-time “fly over” system performance. Thus, a set of
`
`15
`
`19
`
`

`
`
`
`low-resolution view tiles can reside in memory of the client and be used by the
`
`client when needed. Ex. 1004 ¶¶40, 44.
`
`53. Unlike Reddy’s specialized client software, Hornbacker operates
`
`through HTTP requests from a web browser specifically to avoid the type of
`
`specialized client workstation image view software
`
`that
`
`is employed in
`
`TerraVision II, the specialized VRML browser described in Reddy.1 See Ex. 1003,
`
`2:24–26, 14:17–28. The Hornbacker server creates tiles on demand in response to
`
`each user request, a computationally intensive and inefficient process that a POSA
`
`would have understood does not make sense in the context of a goal of a real-time,
`
`“fly over” system. View tiles are not generated in advance because Hornbacker
`
`creates custom tiles based on specific requests for a particular view (for example,
`
`at the rotation angle and scale requested), which cannot be used by another client
`
`who requests a slightly different angle or scale. Ex. 1003 ¶54. I therefore
`
`respectfully disagree with Petitioner and Dr. Michalson that Reddy and
`
`Hornbacker take similar approaches. See Ex. Paper 2, p.19; Ex. 1005 ¶105.
`
`54. For claims 21–22, a POSA would not have considered Loomans for
`
`combination with Hornbacker and Reddy to cure the deficiencies in Reddy because
`
`
`1 TerraVision II is a real-time, distributed terrain visualization system that was designed to
`
`enable interactive visualization of massive terrain databases that can be distributed over a high-
`
`speed wide-area network. See generally Ex. 1004.
`
`16
`
`20
`
`

`
`
`
`Loomans is in an unrelated field and takes the opposite approach to that of
`
`Hornbacker. It is my opinion that Loomans is generally directed to downloadable
`
`web applets, particularly
`
`for e-commerce, which can manage multiple
`
`asynchronous threads. See Ex. 1014, 1:46–55, 2:61–63, 3:1–30, 3:46–49, 6:1–5;
`
`6:15–17.
`
`55. Loomans makes no mention of GIS, image transfer, or 2D or 3D
`
`terrain modeling. Loomans describes in the shortcomings of existing e-commerce
`
`applications, including that they do not scale well because server-side processing is
`
`slow and scales poorly. See Ex. 1014, 3:1–30. The invention of Loomans attempts
`
`to minimize
`
`server-side complexity by adding
`
`thread-management
`
`to
`
`downloadable client-side applets. See Ex. 1014, 3:1–30; 3:46–49. Utilizing client
`
`processing to reduce load on the servers is in direct conflict with Hornbacker’s
`
`approach. The invention of Hornbacker is an exclusively server-side image
`
`processing system. See Ex. 1003 Title (“Network Image View Server”), pp.2–3
`
`(“It is another object to minimize computing resources required by a client
`
`workstation.”); 5 (“No software other than a Web browser is required on the
`
`client.”).
`
`56. Further, Loomans’ processing-intensive client-side application is the
`
`opposite approach of the ’239 patent, whose invention is directed to small clients
`
`with limited memory and resources. See Ex. 1014, 6:1–5 (“all processing of user
`
`17
`
`21
`
`

`
`
`
`inputs and calculation results is carried out on the client platform”). I therefore
`
`respectfully disagree with Petitioner’s assertion that Loomans is similar to Reddy
`
`and Hornbacker because it “discloses using web browsers” and operates over a
`
`low-bandwidth network while maintaining interactivity for the user is overly broad
`
`(see Paper 2, pp.60–61). The selection of Loomans for this Petition sticks out like
`
`a red thumb next to the other asserted references, which, in my opinion, suggests
`
`that Loomans was selected solely to map prior art in hindsight to claim elements
`
`rather than being guided by what a POSA would know or look to. A POSA would
`
`not have looked to Loomans in combination with Reddy and/or Hornbacker.
`
`B. Discussion of Reddy, Hornbacker, and Loomans
`
`Reddy
`
`1.
`57. The Reddy reference is directed to a specialized client workstation
`
`image viewing software operating on a conventional, fixed site computer system
`
`over a high bandwidth
`
`internet connection.
`
` Funded by
`
`the DARPA
`
`Multidimensional Applications Gigabit Internet Consortium II contract (Ex. 1004,
`
`p.37 (Acknowledgements)), Reddy describes a specialized, client-side VRML
`
`browser called TerraVision II as well as a system of generating VRML terrain files
`
`from geographic data (see generally Ex. 1004). TerraVision II is a real-time,
`
`distributed terrain visualization browser that was designed to enable interactive
`
`visualization of massive terrain databases that can be distributed over a high-speed
`
`18
`
`22
`
`

`
`
`
`wide-area network. Ex. 1004 ¶38. TerraVision II relies on a complex, interlaced
`
`hierarchy of tree files that include a hierarchy of “Geotiles” that further contain
`
`links to terrain tile files, as well as satellite, aerial, and map imagery and features.
`
`Ex. 1004, p.33. TerraVision II can be implemented on graphics workstations
`
`connected to gigabit-per-second ATM networks with high-speed disk servers as
`
`well as desktop PCs connected to the Internet. See Ex. 1004 ¶48. Reddy requests
`
`images tiles through the VRML ImageTexture node, which has a URL saved for
`
`that particular object.
`
`2. Hornbacker
`58. The Hornbacker reference is directed to a “Network Image View
`
`Server,” which is designed to eliminate the problem of requiring “specialized client
`
`workstation image view software,” Ex. 1003 Title; Abstract, the very type of
`
`system described in Reddy. Hornbacker thus avoids a specific client-side
`
`application, in favor of a server architecture that can efficiently distribute image
`
`tiles to a web browser at a URL through HTTP requests. Ex. 1003, p.3.
`
`Hornbacker does not describe the client system beyond noting that the workstation
`
`will connect with the server through a web browser. See Ex. 1003, p.5. The client-
`
`side features described in Hornbacker are implemented via HTML. See, e.g., Ex.
`
`1003, p.3.
`
`19
`
`23
`
`

`
`
`
`59. The Hornbacker reference
`
`touts
`
`the avoidance of client-side
`
`applications as a benefit, (Ex. 1003, 14:17–28), and the disclosed system maintains
`
`this benefit even to the extent of including URL request for tiles at a specific angle
`
`of rotation. Ex. 1003, p.9. In other words, tiles are custom-calculated for each
`
`user by the server at whatever specific angle the user happens to request, and
`
`served via URL so that the client system does not need to do the work of rotating
`
`the image. Specifically, Hornbacker requests image tiles by specifying at least
`
`SCALE and TILE_NUMBER in the URL name, using the URL nomenclature to
`
`specify viewing characteristics such as angle, X mirror, Y mirror, and inversion.
`
`Ex. 1003, p.9.
`
`Loomans
`
`3.
`60. The Loomans reference is directed to a “general purpose e-commerce
`
`application,” specifically a “browser resident in a client computer that is typically
`
`used to execute a highly interactive e-commerce application.” Ex. 1014, 1:46–55,
`
`2:61–63, 3:1–3, 6:15–17. Loomans attempts to improve upon conventional
`
`approaches to delivering general purpose e-commerce applications by eschewing
`
`server-side processing as much as possible, finding that “the performance of a
`
`server side application will always be generally slower than an equivalent client
`
`side application” and that “it is difficult to find a general solution to scaling the
`
`server side facility since every time a new user is added, additional processing
`
`20
`
`24
`
`

`
`
`
`capabilities must be provided by the