`
`
`
`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 9,253,239
`____________________
`
`PATENT OWNER BRADIUM TECHNOLOGIES LLC’S
`RESPONSE PURSUANT TO 37 C.F.R. §42.120
`
`NY01:4369027.15
`
`

`

`
`
`I.
`
`II.
`
`TABLE OF CONTENTS
`
`Introduction ...................................................................................................... 1
`
`Overview of the ’239 Patent ............................................................................ 2
`
`A.
`
`B.
`
`Person of Ordinary Skill in the Art ....................................................... 8
`
`Claim Construction ............................................................................... 8
`
`1. “Data Parcel” (Claims 1, 12, 17, 21, 22) ........................................ 8
`
`2. “Image Parcel” (Claims 1, 25) ....................................................... 9
`
`III. Legal Standards ............................................................................................... 9
`
`IV. Claims 1–19 and 22–25 are Not Unpatentable .............................................. 12
`
`A.
`
`B.
`
`Reservation of Rights Regarding Constitutionality of Proceeding ..... 12
`
`Discussion of Reddy, Hornbacker, and Loomans ............................... 12
`
`1. Reddy ............................................................................................ 12
`
`2. Hornbacker .................................................................................... 13
`
`3. Loomans ........................................................................................ 14
`
`C.
`
`The Asserted References Do Not Teach or Suggest All Elements
`of Claims 21 or 22 (Ground 2) of the ’239 Patent .............................. 16
`
`D. A POSA Would Not Have Selected and Combined the Asserted
`References ........................................................................................... 40
`
`1. A POSA would not have selected Reddy ..................................... 40
`
`2. A POSA would not have combined Reddy and Hornbacker ........ 43
`
`3. A POSA would not have combined Reddy or Hornbacker with
`Loomans ........................................................................................ 44
`
`4. Hornbacker and Reddy are incompatible ..................................... 45
`
`5. Hornbacker and Loomans are incompatible ................................. 46
`
`NY01:4369027.15
`
`i
`
`

`

`
`
`6. Austreng teaches away from the asserted combination of Reddy
`and Hornbacker with Loomans. .................................................... 47
`
`V.
`
`Conclusion ..................................................................................................... 49
`
`
`
`
`
`
`
`NY01:4369027.15
`
`ii
`
`

`

`
`
`Patent Owner Bradium Technologies LLC (“Patent Owner”) hereby submits
`
`this Patent Owner’s Response in IPR2016-01897 for U.S. Patent No. 9,253,239
`
`(the “’239 patent”). The Board instituted review of claims 1–19 and 23–25 for
`
`Ground I, obviousness under 35 U.S.C. § 103(a) over the combination of Reddy
`
`and Hornbacker, and of claims 21–22 for Ground II, obviousness under 35
`
`U.S.C. § 103(a) over the combination of Reddy, Hornbacker and Loomans.
`
`Paper 17 (Institution Decision) at 33–34. The Board did not institute review of
`
`claim 20. Paper 17 at 19–20.
`
`The Board extended DUE DATE 1 to August 1, 2017. Paper 22,
`
`amending Scheduling Order (Paper 18).
`
`I.
`
`INTRODUCTION
`
`As to Ground 2, claims 21–22 are not unpatentable at least because the
`
`asserted references do not teach or suggest the claimed method of using concurrent
`
`threads to request and receive update data parcels. In the interest of presenting a
`
`focused response, Patent Owner does not include additional argument regarding
`
`the prior art status of Loomans, however, Patent Owner maintains its position that
`
`Loomans is not prior art. Patent Owner’s argument on the merits shows that, even
`
`if Loomans is considered as prior art, claims 21–22 are not rendered obvious.
`
`Further, the claims are not unpatentable because a POSA would not have
`
`combined asserted references Reddy and Hornbacker (claims 1–19 and 23–25) and
`
`NY01:4369027.15
`
`1
`
`

`

`
`
`additionally Loomans (claims 21 and 22) to arrive at the claimed invention of
`
`the ’239 Patent.
`
`As to all claims on which review has been instituted, claims 1–19 and 21–
`
`25, Patent Owner raises the issue of the constitutionality of the instant
`
`proceeding in order to preserve its rights. The Supreme Court recently granted
`
`certiorari in Oil States Energy Svcs. v. Greene’s Energy Group, No. 16-712
`
`(cert. granted Jun. 12, 2017) regarding the question of whether inter partes
`
`review proceedings violate the Constitution by extinguishing private property
`
`rights through a non-Article III forum without a jury.
`
`Therefore, the instituted claims 1–19 and 21–25 of the ’239 patent are not
`
`unpatentable.
`
`II. OVERVIEW OF THE ’239 PATENT
`The ’239 patent is entitled “Optimized image delivery over limited
`
`bandwidth communication channels”. The Abstract recites in part: “Large-scale
`
`images are retrieved over network communications channels for display on a client
`
`device by selecting an update image parcel relative to an operator controlled image
`
`viewpoint to display via the client device. A request is prepared for the update
`
`image parcel and associated with a request queue for subsequent issuance over a
`
`communications channel. The update image parcel is received from the
`
`NY01:4369027.15
`
`2
`
`

`

`
`
`communications channel and displayed as a discrete portion of the predetermined
`
`image.”
`
`The ’239 patent recites, regarding the field of the invention: “The disclosure
`
`is related to network based, image distribution systems and, 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.” Ex.
`
`1001 at 1:25-33.
`
`The inventors of the ’239 patent developed a method for the retrieval of
`
`large-scale images over limited bandwidth network communications channels or
`
`usable by small client devices. See, e.g., Ex. 1001, 3:10–39; 3:47–51; 4:4–12. A
`
`well-recognized problem in the art at the time of the ’239 patent was that full
`
`resolution image presentation over a network connection may be subject to latency.
`
`Ex. 1001, 1:50–53. Prior art techniques to improve bandwidth utilization in
`
`limited-bandwidth situations relied on computationally intensive compression and
`
`progressive transmission techniques. See, e.g., Ex. 1001, 1:36–2:39. For example,
`
`transmission of differential coefficient sets required the client to perform an
`
`inverse-transform function. See Ex. 1001, 1:64–2:12 (describing Tzou, U.S. Pat.
`
`No 4,698,689). A refinement to that technique employed a computationally
`
`NY01:4369027.15
`
`3
`
`

`

`
`
`intensive function to variably build resolution of the image based on retrieving
`
`coefficient sets. See Ex. 1001, 2:13–39.
`
`With known techniques, significant problems remained in permitting the
`
`effective use of complex images by, for example, small clients with limited
`
`computing capabilities. See Ex. 1001, 2:40–43; 2:47–49; 3:10–12. Conventional
`
`approaches presumed an excess of computing performance, memory, storage, and
`
`relatively high-bandwidth networks. See Ex. 1001, 1:45–47; 2:47–49. A small
`
`client at the time of the invention would be expected to have limited processing
`
`capacity and memory. See Ex. 1001, 2:49–53. These small clients typically
`
`operated under wireless conditions with very limited network bandwidths. See Ex.
`
`1001, 3:10–12.
`
`Further, with known techniques, significant problems remained in
`
`transmitting image data over networks in high latency, limited-bandwidth
`
`environments. See Ex. 1001, 1:45–2:61.
`
`The ’239 patent overcame limitations of the prior art by providing for large
`
`image retrieval through a number of novel techniques, including: “the prioritization
`
`of image parcel requests [] based on an adaptable parameter that minimizes the
`
`computational complexity of determining request prioritization”; and the “re-
`
`prioritization of image parcel data requests and presentation.” E.g., Ex. 1001,
`
`3:65–4:3; 4:4–12; 4:13–20.
`
`NY01:4369027.15
`
`4
`
`

`

`
`
`The ’239 patent also teaches a variety of multi-threading techniques that
`
`work with the prioritization of image parcel requests to effectively download
`
`portions of an image to be displayed. Figure 5 is a process flow diagram showing
`
`a main processing thread implemented in a preferred embodiment (Ex. 1001 at
`
`5:1–3):
`
`
`
`“The client architecture 40 preferably executes in multiple process threads,
`
`with additional threads being utilized for individual network data request
`
`transactions. As shown in FIG. 5, an image parcel management process 80
`
`implements a loop that determines image parcels subject to update 82 and creates
`
`corresponding image parcel download requests 84.” Ex. 1001 at 8:30–35.
`
`The ’239 patent teaches that “a pool of image request threads is preferably
`
`utilized to manage the image parcel download operations. In the preferred
`
`NY01:4369027.15
`
`5
`
`

`

`
`
`embodiments of the present invention, a pool of four network request threads is
`
`utilized. The number of pool threads is determined as a balance between the
`
`available system resources and the network response latency, given the available
`
`bandwidth of the network connection.” Ex. 1001 at 8:41–47. Figure 6 is a process
`
`flow diagram for a network request thread implemented in a preferred
`
`embodiment. Ex. 1001 at 5:4–6.
`
`
`
`“When a network request thread becomes available, the process 100
`
`examines 106 all of the pending requests in the priority request queue 52 and
`
`selects 108 the request with the highest assigned priority. Thus, sequentially
`
`enqueued requests can be selectively issued out of order based on an independently
`
`assigned request priority. The request is then issued 110 and the request
`
`management process 100 leaves the request thread waiting on a network response.”
`
`Ex. 1001 at 9:8–16.
`
`Figure 7 is a process flow diagram showing a display image rendering thread
`
`implemented in a preferred embodiment. Ex. 1001 at 5:7–9.
`
`NY01:4369027.15
`
`6
`
`

`

`
`
`As taught by the ’239 patent, for the display management process 120 shown
`
`
`
`in Figure 7, “[e]vent driven user navigation information is evaluated 122 to
`
`determine a current viewing frustum location and orientation within a three-
`
`dimensional space relative to the displayed image. An algorithmic priority
`
`selection 124 of a next image parcel to render is then performed. The selected
`
`image parcel is then rendered 126 to the display memory 70. The rendering
`
`operation preferably performs a texture map transform of the parcel data
`
`corresponding to the current viewing frustum location and orientation.” Ex. 1001
`
`at 9:17–26. The process 120 then continues to select the next image parcel to
`
`render, comprehending any change in the viewing frustum location and orientation.
`
`Ex. 1001 at 9:31–33.
`
`NY01:4369027.15
`
`7
`
`

`

`
`
`Person of Ordinary Skill in the Art
`
`A.
`The Board, noting that “we do not perceive any meaningful difference
`
`between the parties’ definitions of the technical field of the required experience,”
`
`has stated that a person of ordinary skill in the art at the time of the invention (or
`
`“POSA”) of the U.S. Patent 7,908,343 (the “’343 patent”) and U.S. Patent
`
`8,924,506 (the “’506 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.” IPR2016-00448 at
`
`Paper 69 at 12; IPR2016-00449 at Paper 67 at 15. As the ’239 Patent claims
`
`priority through the ’343 and ’506 patents, Patent Owner applies this
`
`understanding of a POSA for purposes of this inter partes review.
`
`B. Claim Construction
`The Board has construed certain claim terms pursuant to the broadest
`
`reasonable interpretation (BRI) for the sole purpose of this inter partes review
`
`proceeding as set forth below.
`
`“Data Parcel” (Claims 1, 12, 17, 21, 22)
`
`1.
`Petitioner proposed that “data parcel” be construed in all claims as “data that
`
`corresponds to an element of a source image array.” Petition at 12. Patent Owner
`
`does not disagree with Petitioner’s proposal. The Board has construed the claim
`
`NY01:4369027.15
`
`8
`
`

`

`
`
`term “data parcel” as meaning “data that corresponds to an element of a source
`
`image array.” Paper 17 at 8.
`
`“Image Parcel” (Claims 1, 25)
`
`2.
`The Board has construed “image parcel” to be “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.” Paper 17 at 9.
`
`III. LEGAL STANDARDS
`Petitioner has the burden to show that it is likely to prevail as to at least one
`
`claim of the ’239 patent. 35 U.S.C. § 314. Both of Petitioner’s Grounds rely on
`
`obviousness combinations. To make a prima facie showing of obviousness under
`
`35 U.S.C. § 103, the Petition must, among other requirements, fulfill the
`
`requirements set forth in Graham v. John Deere Co., 383 U.S. 1 (1966), including
`
`demonstrating that the cited references, in combination, disclose each element of a
`
`challenged claim. In re Magnum Oil Tools Int’l., 829 F.3d 1364, 1376 (Fed. Cir.
`
`2016); see Apple Inc. v. Contentguard Holdings, Inc., IPR2015-00442, Paper 9 at
`
`12 (July 13, 2015).
`
`Petitioner also has the burden to show whether there would have been a
`
`motivation to combine the asserted prior art, and whether the proposed
`
`combination would render the patented claims obvious. In re Magnum Oil Tools
`
`Int’l., 829 F.3d at 1376 (Fed. Cir. 2016).
`
`NY01:4369027.15
`
`9
`
`

`

`
`
`A petition must provide an explicit rationale to make proposed modifications
`
`to or combinations of the prior art references, despite the differences between the
`
`claimed invention and the prior art, without relying on the patent disclosure itself.
`
`Apple Inc. v. Contentguard, Paper 9 at 15; see also Proctor & Gamble Co. v. Teva
`
`Pharm. USA, Inc., 566 F.3d 989, 995 (Fed. Cir. 2009).
`
`A petition must also explain why a person of ordinary skill in the art would
`
`simultaneously make multiple changes and implementation choices to arrive at a
`
`particular invention. Apple Inc. v. Contentguard, Paper 9 at 16-17 (“[W]e are not
`
`persuaded that the Petition sufficiently explains why a person of ordinary skill
`
`would simultaneously make all of the many particular proposed changes and
`
`implementation choices”) (internal citations omitted). Even if individual
`
`modifications or choices were obvious, a petition must explain why making all of
`
`the changes at once would be obvious. Id. at 17 (“[T]he mere fact that individual
`
`changes might have been obvious does not make doing all of the changes at once
`
`obvious.”).
`
`Most inventions rely on known building blocks, so Petitioner must show that
`
`a POSA would both select and combine the building blocks “in the normal course
`
`of research and development to yield the claimed invention.” Microsoft Corp. v.
`
`Bradium Techs. LLC, IPR2015-01432, Paper 51 (P.T.A.B. Dec. 21, 2016), p.14,
`
`citing Unigene Labs., 655 F.3d at 1360 (citing KSR, 550 U.S. at 421). It is
`
`NY01:4369027.15
`
`10
`
`

`

`
`
`important to identify a reason and motivation that would have prompted a POSA to
`
`combine the prior art elements in the way claimed in the challenged patent, to
`
`achieve the invention. Proctor & Gamble Co. v. Teva Pharms. USA, Inc., 566
`
`F.3d 989, 994 (Fed. Cir. 2009); KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 418–
`
`19 (2007). “Obviousness 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) (citing KSR, 550 U.S.at 418). The lack of a technological obstacle to
`
`combining references, in and of itself, does not justify a finding of obviousness.
`
`See In re Omeprazole Patent Litigation, 536 F.3d 1361, 1380-81 (Fed. Cir. 2008).
`
`A reason for combining disparate prior art references is critical and should be made
`
`explicit. InTouch Tech., Inc. v. VGo Communs., Inc., 751 F.3d 1327, 1351 (Fed.
`
`Cir. 2014) (citing KSR, 550 U.S. at 418).
`
`Hindsight analysis is inappropriate; obviousness must be measured “at the
`
`time the invention was made.” Ortho-McNeil Pharm. v. Mylan Labs, 520 F.3d
`
`1358, 1364 (Fed. Cir. 2008) (emphasis in original). The Petitioner must not use
`
`the patent as a roadmap. In re NTP, Inc., 654 F.3d 1279, 1299 (Fed. Cir. 2011)
`
`(citing Grain Processing v. American-Maize Prods, 840 F.2d 902, 907 (Fed. Cir.
`
`1988)); see also KSR, 550 U.S. at 421.
`
`NY01:4369027.15
`
`11
`
`

`

`
`
`IV. CLAIMS 1–19 AND 22–25 ARE NOT UNPATENTABLE
`A. Reservation of Rights Regarding Constitutionality of Proceeding
`The Federal Circuit has held that inter partes review proceedings are
`
`constitutional. MCM Portfolio LLC v. Hewlett-Packard Co., 812 F.3d 1284, 1288-
`
`92 (Fed. Cir. 2015), cert. denied, 137 S. Ct. 292. However, on June 12, 2017, the
`
`Supreme Court granted certiorari in Oil States Energy Servs., LLC v. Greene’s
`
`Energy Grp., LLC, No. 16-712, 2017 WL 2507340 (U.S. June 12, 2017), to
`
`consider the following question: “1. Whether inter partes review – an adversarial
`
`process used by the Patent and Trademark Office (PTO) to analyze the validity of
`
`existing patents – violates the Constitution by extinguishing private property rights
`
`through a non-Article II forum without a jury.” In the event that the Supreme
`
`Court concludes that inter partes review proceedings are unconstitutional, Patent
`
`Owner reserves its right to argue that this ruling is applicable in the present inter
`
`partes review, and that the inter partes review should be dismissed as
`
`unconstitutional. Patent Owner further reserves its rights to appeal the Board’s
`
`determination, should the Board conclude that one or more instituted claims are
`
`unpatentable, based on the outcome of Oil States.
`
`B. Discussion of Reddy, Hornbacker, and Loomans
`1.
`Reddy
`Reddy is directed to a specialized client workstation image viewing software
`
`operating on a conventional, fixed site computer system over a high bandwidth
`
`NY01:4369027.15
`
`12
`
`

`

`
`
`internet connection. Ex. 2014, ¶40. Funded by the DARPA Multidimensional
`
`Applications Gigabit Internet Consortium II contract (Ex. 1004 at 37
`
`(Acknowledgements)), Reddy describes the generation of VRML terrain files from
`
`geographic data and a specialized client-side VRML browser TerraVision II for
`
`viewing these files (see generally Ex. 1004). Ex. 2014, ¶41. 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. Ex. 1004, ¶38. TerraVision 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. E.g., Ex. 1004, p.33 (figure); Ex. 2014, ¶42. 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. Ex. 2014,
`
`¶43.
`
`2. Hornbacker
`Hornbacker is directed to a “Network Image View Server,” which is
`
`designed to eliminate the problem of requiring “specialized client workstation
`
`image view software,” the very type of system described in Reddy. Ex. 1003,
`
`NY01:4369027.15
`
`13
`
`

`

`
`
`Title; Abstract. 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.
`
`Hornbacker 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. Ex. 2014, ¶45.
`
`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; Ex. 2014, ¶46.
`
`Loomans
`
`3.
`Loomans 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–
`
`NY01:4369027.15
`
`14
`
`

`

`
`
`63, 3:1–3, 6:15–17; Ex. 2014, ¶47. 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 capabilities must be provided by the server.” See Ex. 1014, 3:1–20; Ex.
`
`2014, ¶48.
`
`Accordingly, Loomans relies on a downloadable application engine kernel,
`
`which downloads a larger kernel, and so on until user requests can be processed.
`
`See Ex. 1014, 5:9–31. The application runs client-side through an HTML page,
`
`minimizing server-side processing. See id.; Ex. 2014, ¶49 In response to a user
`
`HTTP request identified by a URL (universal resource locator), in conjunction
`
`with kernel bootstrapping, the application shell pages loads both initial GUI
`
`(graphical user interface) components and data components. Ex. 1014 at 5:1-55.
`
`The application can then proceed to process user input in the context of the
`
`received data. The results of the particularized processing are displaced, if
`
`required, using additional HTML pages. In almost all cases, a user session will
`
`consist of a series of different sub-applications as the user navigates and interacts,
`
`each with its own particularized UI and data. Ex. 1014 at 5:41-45.
`
`NY01:4369027.15
`
`15
`
`

`

`
`
`Loomans describes a preferred embodiment of this browser environment
`
`application, which provides thread management routines to improve user
`
`interaction in an asynchronous environment, i.e. the browser. See Ex. 1014, Title,
`
`3:52–62 (Summary of the Invention) (emphasis added); Ex. 2014, ¶49.
`
`C. The Asserted References Do Not Teach or Suggest All Elements of
`Claims 21 or 22 (Ground 2) of the ’239 Patent
`
`As to Ground 2, the asserted combination of Reddy, Hornbacker, and
`
`Loomans does not teach or suggest the use of concurrent threads to request and
`
`retrieve update data parcels as recited in claim 21 or claim 22; Ex. 2014, ¶¶50–99.
`
`As shown below, the claims require that source image data be processed into
`
`a series of derivative images. See Ex. 1001 at 6:6–18, 25–28. The derivative
`
`images correspond to data parcels. It is the data parcels that are retrieved by two or
`
`four concurrently executing threads. See, e.g., Ex. 1001 at 8:40-56. The data
`
`parcels correspond to derivative images of a predetermined image, and are split
`
`into separate data parcels in order to effect the retrieval of the images over a
`
`network.
`
`Selected Claims Elements re Request and Receiving Images Over a Network Via
`
`Concurrently Executing Threads
`
`Claim 1: “1. A method of retrieving images over a network communication
`
`channel for display on a user computing device, the method comprising steps of:
`
`NY01:4369027.15
`
`16
`
`

`

`
`
`“issuing a first request from the user computing device to one or more servers . . .
`
`for a first update data parcel corresponding to a first derivative image of a
`
`predetermined image . . . corresponding to source image data . . . .;
`
`“receiving the first update data parcel . . . after the step of issuing the first request;
`
`“issuing a second request from the user computing device to one or more servers . .
`
`. for a second update data parcel corresponding to a second derivative image of a
`
`predetermined image . . ..;
`
`“receiving the second update data parcel . . . after the step of issuing the second
`
`request;
`
`. . .
`
`“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 . . . .”
`
`Claim 21: “A method as in claim 1, wherein:
`
`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; and
`
`NY01:4369027.15
`
`17
`
`

`

`
`
`the first thread and the second thread are executed at least in part concurrently”
`
`Claim 22: “A method as in claim 1, further comprising: . . .
`
`“issuing a third request from the user computing device . . . for a third update data
`
`parcel . . .;
`
`receiving the third update data parcel at the user computing device from the one or
`
`more servers over the one or more network communication channels;
`
`issuing a fourth request from the user computing device . . . for a fourth update
`
`data parcel . . .;
`
`receiving the fourth update data parcel at the user computing device from the one
`
`or more servers over the one or more network communication channels;
`
`wherein:
`
`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 thread, the second thread, the third thread, and the fourth thread are
`
`NY01:4369027.15
`
`18
`
`

`

`
`
`executed at least in part concurrently.”
`
`Petitioner’s argument fails for two reasons. First, because Petitioner relies
`
`on the general disclosure of the concept of multi-threading as teaching or
`
`disclosing the invention of claims 21 and 22, but claims 21 and 22 are not directed
`
`to general multithreading. E.g., Ex. 2014, ¶¶54–57, 78. Second, because as shown
`
`by the references relied upon by Petitioner and Dr. Michalson, multi-threading was
`
`understood at the time to apply to separating out user-interface tasks and
`
`background (i.e., download) tasks, not type of concurrent use of multiple threads to
`
`download to facilitate download of a particular, for example, source image or
`
`object. E.g., Ex. 2014, ¶¶68, 84, 90. Third, because the asserted disclosures of the
`
`asserted references do not teach or suggest the concurrent use of multiple threads
`
`to request and receive data parcels as claimed, and in fact some of the references
`
`teach away from doing so. Ex. 2014, ¶¶68–95. Finally, attempting the combination
`
`would have been unworkable. Ex. 2014, ¶¶96–98.
`
`Claims 21 and 22 require concurrent issuance of requests (and receipt of
`
`responses) for data parcels, which the Board has construed as meaning “data that
`
`corresponds to an element of a source image array.” See Section II.B.1; Ex. 2014,
`
`¶¶27–29, 55, 69. Therefore, the claim reads, for example, “issuing a third request
`
`from the user computing device . . . for a third update [data that corresponds to an
`
`NY01:4369027.15
`
`19
`
`

`

`
`
`element of a source image array] . . .;” The claims are directed to breaking up a
`
`source image into a series of derivative images and downloading these derivative
`
`images via multi-threading. While the concept of multi-threading was part of the
`
`programmer’s toolbox at the time of the invention, the mere concept of multi-
`
`threading was insufficient to teach or suggest the claims. See, e.g., Ex. 2014, ¶¶55,
`
`69.
`
`While Reddy discloses the general concept of multi-threading, and if
`
`anything would guide a POSA away from applying it to concurrent downloading
`
`with multiple threads. Ex. 2014, ¶57. Reddy discloses that TerraVision II is “a
`
`multi-threaded application” (Ex. 1004 at ¶41) and that “[m]ost VRML browsers
`
`perform nonblocking network reads so that the user can still interact with the scene
`
`while higher resolution imagery and elevation loads.” (Ex. 1004 at ¶21
`
`(underlining added).) Reddy does not disclose how multi-threading might be used.
`
`Ex. 2014, ¶57. These general disclosures in an application would not suggest to a
`
`POSA that multi-threading would be used for concurrent image download. Ex.
`
`2014, ¶¶54–59. The underlined portion of Paragraph 21 of Reddy in fact suggests
`
`that multi-threading may be used to enable user interaction while downloading
`
`occurs in the background, rather than for parallel network reads.
`
`Austreng, in fact, affirms that as suggested by Reddy, multi-threading was
`
`generally understood to be useful in the form of separate threads for separate tasks
`
`NY01:4369027.15
`
`20
`
`

`

`
`
`such as graphical rendering and downloading, not for multiple threads for the same
`
`task (i.e., image downloading). Ex. 2014, ¶68. Austreng, in providing background
`
`information regarding JAVA, explains JAVA as providing a separate GUI thread
`
`(thread interacting with the user) and worker thread (thread performing a time-
`
`consuming operation). Ex. 1016 at 6:20-22 (“For example, one thread may be
`
`displaying an image in a WEB page while a second thread is downloading other
`
`images to display.”). Ex. 2014, ¶68.
`
`Most tellingly, Austreng (Ex. 1016) discloses, in accordance with the
`
`general understanding that multi-threading would be directed to splitting up user-
`
`interface tasks and background/download tasks, rather than having multiple threads
`
`handle downloading for a particular object, that images are downloaded in series
`
`(one-by-one), even in a multi-threaded environment. Ex. 2014, ¶¶71–83.
`
`Austreng discloses that, in the context of three-dimensional image browsers, when
`
`multithreading is used, a single thread should be used for image downloads, while
`
`other threads are directed to display and rendering. Austreng (Ex. 1016) at 4:11-16,
`
`6:20-22. Figure 4 shows the general architecture of Austreng. Ex. 1016 at 5:12
`
`(“FIGURE 4 is a block diagram illustrating the class structure of the invention;”).
`
`Figure 4 illustrates the class and important methods of the invention of Austreng.
`
`The ThreeDObject (304, see middle of Figure 4) class defines the methods of the
`
`invention. For the series of two-dimensional images for a particular three-
`
`NY01:4369027.15
`
`21
`
`

`

`
`
`dimensional object, one method, initImages (308, right-top of Figure 4) performs
`
`initialization related to images then downloads and displays the first image.
`
`Austreng, 13:12-14. Another method, validateData (310, second from top-right of
`
`Figure 4) downloads the remaining two-dimensional images. Ex. 1016 at 13:14–
`
`16.
`
`
`
`Austreng at Figure 4.
`
`
`
`In Austreng, one instance 322 of ThreeDOObject applet is created per applet
`
`tag 210 in HTML page 202. Ex. 1016 at 14:5–7.