`
`DECLARATION OF YONATAN LAVI
`
`1. My name is Yonatan Lavi. I live in Tel Aviv, Israel. I am providing this
`
`declaration based on my personal knowledge and I am not being
`
`compensated for providing this declaration.
`
`2. I have been informed by attorneys for Microsoft Corporation (“Microsoft”)
`
`that Bradium has asserted several patents which list me as a co-inventor,
`
`along with Isaac Levanon. I understand that these patents include U.S.
`
`Patent Nos. 7,139,794 B2 (“the ‘794 Patent”), 7,908,343 B2 (“the ‘343
`
`Patent”), 8,924,506 B2 (“the ‘506 Patent), and 9,253,239 B2 (“the ‘239
`
`Patent”). I understand that all of these patents are related to six provisional
`
`U.S. patent applications filed on December 27, 2000, which also list myself
`
`and Mr. Levanon as co-inventors. In this declaration, I will discuss my
`
`knowledge of 3DVU, Inc. and 3DVU, Ltd. (collectively, “3DVU”),1 which
`
`originally filed these patent applications.
`
`3. I was first hired to work at 3DVU (then known as GACentral.com, Inc.) by
`
`Isaac Levanon in mid-1999 as a software developer. I, along with two other
`
`
`1 3DVU was originally formed as GACentral.com, Inc. and changed its name to
`FlyOver Technologies, Inc. in early 2000 before changing its name again to
`3DVU. 3DVU, Ltd. was set up as a subsidiary of 3DVU, Inc., which was a US
`company. To avoid confusion, I will refer to all of these companies as “3DVU”
`unless the difference is relevant to a particular issue.
`
` 1
`
`
`
`
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`developers, Ohad Eder-Pressman and Eyal Navon, started working
`
`informally for Mr. Levanon and his company (3DVU) shortly after I
`
`graduated from high school. The three of us worked essentially as
`
`independent contractors (although there was no formal employment or other
`
`contract at the time) for a few months spanning the years 1999-2000. My
`
`recollection is that Mr. Levanon communicated mostly with Mr. Eder
`
`Pressman, although the three of us were paid individually. All three of us
`
`were offered (and I accepted) shares of stock in the company in the year
`
`2000. Mr. Eder-Pressman and Mr. Navon were also recent high school
`
`graduates with some software development experience who were contracted
`
`by Mr. Levanon to write code for 3DVU. Mr. Levanon’s role was primarily
`
`running the company, rather than in developing software. Mr. Levanon was
`
`not a computer programmer, and my recollection is that at that time and
`
`throughout the time that I worked at 3DVU he did not have the ability to
`
`write software code himself.
`
`Original 3DVU prototype and 2000-2001 patent applications
`
`4. When I initially worked for 3DVU in 1999 and 2000, 3DVU was primarily
`
`focused on developing a prototype of a website for visualizing aerial
`
`imagery for an area such as an airport. In particular, we wanted to develop a
`
` 2
`
`
`
`
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`website that might be used to show pilots a perspective view of the area
`
`around an airport, which was the scenario that many of our early efforts
`
`were designed around. The “GA” in the original name of the company was
`
`short for “general aviation.” Mr. Levanon wanted the prototype to offer
`
`pilots the ability to simulate flying over an aerial photograph of an airfield.
`
`For example, Ex. B to a declaration that Mr. Levanon filed on January 10,
`
`2006 during the prosecution of Application No. 10/035,981 (which became
`
`the ‘794 Patent) shows how the “FlyOver” imagery was part of a website
`
`showing information about an airfield:
`
`
`I have attached a true and correct copy of the same document to this declaration as
`
`
`
` 3
`
`Exhibit A.
`
`
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`5. The “FlyOver” imagery in the 1999-2000 prototype basically took a two-
`
`dimensional image (like an aerial or satellite photograph) and transformed it
`
`(performing trigonometric calculations to determine where pixels from the
`
`image would appear on the screen) to create a view from a simulated
`
`perspective. The process of transforming a 2D image to view it from a
`
`three-dimensional perspective was already very well-known at the time,
`
`such as in texturing in video game applications. This original prototype also
`
`did not include any elevation data or way to visualize elevation data, so any
`
`scene that a user looked at with the “FlyOver” viewer would have looked
`
`like a flat plain or plateau, even if the user was looking at satellite or aerial
`
`photographs of a place with hills and valleys or other terrain.
`
`6. The prototype also used a technique called “MIP-mapping,” which is a basic
`
`computer graphics concept that I knew was well-known long in the industry
`
`before any work that we did at 3DVU. For example, the OpenGL software
`
`rendering library, which was developed by Silicon Graphics, used MIP-
`
`mapping extensively. In MIP-mapping, a source image is first divided up
`
`into a series of sub-images, which we sometimes referred to as image parcels
`
`or tiles. These sub-images are then down-sampled into a series of derivative
`
`images at progressively lower resolution. Progressively improving the
`
` 4
`
`
`
`
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`resolution of an image by gradually replacing lower-resolution mip-mapped
`
`versions of the image with higher-resolution versions of the image was also
`
`well-known. For example, many video games used mip-mapped textures to
`
`whose resolution would be progressively enhanced as the viewpoint
`
`approached a portion of the scenery. In fact, as I discuss further, the original
`
`3DVU prototype used a mip-mapped file format called FXT1 which was
`
`originally developed by another company for texture compression in video
`
`games.
`
`7. Although the overall process was not new, we did develop what we thought
`
`were some improvements to the way that image parcels in a MIP-map could
`
`be stored on a server and requested by a client. The 3DVU prototype in
`
`1999-2000 stored the image data for a large set of tiles within a single large
`
`file (a master index file) that had a specified format. The idea of storing
`
`smaller bits of data within a larger file was also something that was well-
`
`known before we built this prototype, but most systems used a “lookup
`
`table” at the beginning of the file that listed the “offset” (distance from the
`
`start of the file, measured in bits or bytes) to the desired data. Ohad Eder-
`
`Pressman, who worked with us at 3DVU, figured that the system could skip
`
`using the lookup table if all of the tiles within the file were the same byte
`
` 5
`
`
`
`
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`size. If the tiles were all the same size, the client device could simply
`
`calculate the offset based on the X, Y position of the tile and the level of the
`
`tile within the hierarchy of resolutions. Calculating offsets in this manner
`
`also required a variable in the code (TileSize) for the size of the tile.
`
`8. We described this method of calculating offsets for fixed byte size tiles in a
`
`Declaration that Mr. Levanon and I submitted to the U.S. Patent and
`
`Trademark Office on June 13, 2006 in support of the application that became
`
`the ‘794 Patent. As we explained on page 3/110 of that Declaration:
`
`9. In the same declaration, we also provided an example of the code which the
`
`prototype used. The code at page 20/110 of this declaration shows how to
`
`calculate offsets within the master index file to locate particular tiles:
`
`
`
`
`
` 6
`
`
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`
`10. This source code used a formula to calculate the byte offset for a particular
`
`tile based on the size of each tile and the X, Y position and level of each tile.
`
`11. As noted above, we also used compression to reduce the size of each data
`
`block corresponding to an image parcel (tile). However, in order to preserve
`
`the system of locating tiles by calculating offsets rather than using a lookup
`
`table, we used a variation of a texture compression format, known as FXT1,
`
`which had a fixed compression rate per pixel, so that a tile of a given size
`
`measured in pixels would always be the same size as measured in bytes.
`
`
`
` 7
`
`
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`FXT1 was an open source texture compression format released by a
`
`company called 3dfx in around 1998-1999, designed mainly for video
`
`games. We (at 3DVU) did not invent this file format, we simply used it
`
`(with slight modifications) for our application.
`
`12. For example, as we mentioned on page 7/110 of the June 13, 2006
`
`Declaration:
`
`13. The requirement for fixed byte size tiles based on fixed ratio compression is
`
`
`
`also reflected in the patents that were eventually filed based on the
`
`provisional applications that 3DVU filed in December 2000. The ‘343
`
`Patent states at column 6, lines 19-22 that “[t]he preferred compression
`
`algorithm may implement for example a fixed 4:1 compression algorithm
`
`such that each compressed and stored image parcel has a fixed 2K byte
`
`size.” The same sentence appears in the ‘506 Patent at column 6, lines 25-
`
`28 and in the ‘239 Patent at column 6, lines 21-24. All of the independent
`
`clams of the ‘343 Patent and ‘506 Patent also say that the tiles have to be
`
`
`
` 8
`
`fixed byte size.
`
`
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`14. One of the intended purposes of the prototype that we built in 1999-2000
`
`was to operate over “narrowband” communication channels, or
`
`communication channels with limited bandwidth. For example, the
`
`prototype that we built in 1999-2000 used a dial-up modem connection, and
`
`such modems at the time typically offered speeds such as 56 KBps, 28.8
`
`KBps, 14.4 KBps, or even lower.
`
`15. In our design of the prototype, limits on processing power and the limits on
`
`bandwidth were distinct issues. For example, the size of the tiles was an
`
`aspect of the design that affected the bandwidth over which the system could
`
`successfully operate, while the manner in which tiles were rendered and
`
`displayed was a design consideration that could affect how much computing
`
`power was required to successfully operate the device. While these
`
`considerations could occur in the same device, they were also independent
`
`of each other (for example, if a computer with a powerful processor was
`
`connected to the Internet with a very slow connection, or if a device with
`
`limited processing and rendering power was connected to the Internet with a
`
`fast connection) and I did not consider limited bandwidth and the processing
`
`power of the device (or the size or shape of the computing device) to be
`
` 9
`
`
`
`synonymous or interchangeable.
`
`
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`16. We (at 3DVU) did not attempt to operate any of the software on a Personal
`
`Digital Assistant (PDA) or other mobile computer system, or otherwise write
`
`special adaptations in the code specific to mobile operating systems, before I
`
`left for the IDF, or before the first provisional applications for patents
`
`relating to this prototype were filed in December 2000. My recollection is
`
`that the testing of our prototype in 1999-2000 was all on a browser interface
`
`operating on a standard home desktop personal computer. I do not recall
`
`exactly what model of computer or computers we used, but to the best of my
`
`recollection, the computers that we used for our prototype would have most
`
`likely had a processor such as an Intel Pentium II or III or a processor of
`
`similar computing power.
`
`17. The software used in the original prototype, both for the server and for the
`
`client, was written primarily in standard C++ code. The original software
`
`was not written specifically for a mobile or embedded system. However,
`
`adapting the software for a PDA later on would have been a straightforward
`
`matter because the Windows CE (later Windows Mobile) mobile operating
`
`platform was designed to maximize the overlap in functionality with the
`
`Windows desktop environment, precisely so that developers could easily
`
`adapt Windows desktop applications for mobile use. The original software
`
`
`
`
`10
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`also used standard, pre-existing network protocols to send and receive data,
`
`and the code was not specialized for the network layer.
`
`18. I do not believe that we ever sold or licensed the “flyover” prototype.
`
`Additionally, significant development work and many changes to the code
`
`and the software took place between the original “flyover” prototype and the
`
`products that 3DVU worked on in later years, such as the Denso car
`
`navigation system and the Navi2Go app, which I will discuss further in this
`
`declaration.
`
`19. I left 3DVU in March 2000 in order to begin my compulsory service in the
`
`Israel Defense Forces (IDF). I served in the IDF as a scientific programmer
`
`with the unit 8200, which is the Israeli Intelligence Corps unit responsible
`
`for collecting signal intelligence and code decryption. I served in the IDF
`
`for approximately 3 years. During the time that I was in the IDF, I had
`
`occasional contact with Isaac Levanon either when required me to sign
`
`something or when someone at 3DVU had a technical question. However,
`
`since I was on active duty in the IDF, my focus was on my military duties.
`
`3DVU’s role in vehicle navigation products
`
`20. I returned to 3DVU full-time when my military service was complete in
`
`March 2003. At this time, 3DVU was working with a company called
`
`
`
`
`11
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`Denso, which had a line of car navigation products. These Denso car
`
`navigation products used satellite or aerial imagery to show the route, in
`
`addition to simple maps. 3DVU’s role in the development of this product
`
`consisted of processing the image data that was used in the navigation
`
`product, and rendering it with 3d perspective into a bitmap layer in real time.
`
`The user interface was designed primarily by Denso and would interact with
`
`the 3DVU portion of the software by making calls to an Application
`
`Programmer Interface (API), which 3DVU provided. Denso sold the final
`
`products in Japan under either the Kenwood or Daewoo brand names.
`
`21. The final car navigation products consisted of a self-contained in-car
`
`navigation system, which stored all navigation data on a hard drive. This
`
`system did not download data over the Internet, or any other network. There
`
`were two major generations of these car navigation products released in
`
`2002 and 2003. These car navigation products did not include any digital
`
`elevation model or digital terrain model. In other words, these products only
`
`showed the user a perspective view of flat imagery, without any
`
`representation of terrain. For example, a video on Mr. Levanon’s YouTube
`
`account (available at https://www.youtube.com/watch?v=3btUNuCYM6M)
`
`shows what the early version of the Denso system looked like in operation,
`
`
`
`
`12
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`and it is clear out several points in the video (note the horizon at, for
`
`example, 1:27 and 2:06-2:25) that the imagery being displayed only shows
`
`the imagery as a flat surface, and does not represent the terrain with an
`
`elevation model:
`
`
`
`
`22. One significant difference between the first and second generations of the
`
`car navigation products is that the first generation used fixed ratio
`
`compression, while the second generation used variable ratio compression
`
`based on JPEG. JPEG compression effectively stores a series of numbers
`
`
`
`
`13
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`representing the mathematical characteristics of waves that can be used to
`
`reconstruct an image, rather than a pixel-by-pixel bit map of an image.
`
`Compressing different images using JPEG, even if the uncompressed images
`
`are the same size in pixels and bit depth per pixel, will result in compressed
`
`images that have different byte sizes. This is referred to as “variable
`
`compression ratio.” Variable ratio compression allowed us to use much less
`
`memory than fixed ratio compression because variable compression achieve
`
`higher average compression ratios. This was important in the car navigation
`
`products for Kenwood because the entire navigation database was stored on
`
`a hard drive, and therefore efficient use of memory was a significant
`
`consideration. After we began using variable ratio compression in 3DVU
`
`products, we did not go back to using fixed ratio compression for any later
`
`3DVU product.
`
`Improvements to 3DVU technology after 2000-2001
`
`23. After I returned to 3DVU from the IDF, I started working on an improved
`
`algorithm for digital elevation modeling. I do not recall any development of
`
`digital elevation modeling before I left for my military service in 2000, and I
`
`am unaware if 3DVU had started experimenting on digital elevation
`
`modeling during the time that I was gone for my military service. However,
`
`
`
`
`14
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`no digital elevation modeling had been incorporated into the car navigation
`
`product before I finished my military service and came back to 3DVU as an
`
`employee. I spent a large amount of my time after returning from my
`
`military service working on improving the digital elevation model.
`
`24. The digital elevation model basically consisted of a database containing
`
`elevation data for geographic regions. A digital terrain model is a 3-D
`
`representation of terrain that uses the coordinates of points in space (based
`
`on some sort of mapping data containing elevations) as the vertices for a
`
`model that represents the surface of the earth. A well-known challenge in 3-
`
`D modeling, including modeling terrain surfaces, was how to manage digital
`
`terrain models at varying levels of detail. The problem is roughly analogous
`
`to the level of detail challenge in displaying textures. For example, a digital
`
`terrain model at a high resolution (that is, with a high number of vertices)
`
`can take a lot more system resources to load or download. However, a
`
`digital terrain model at a low resolution (that is, with a low number of
`
`vertices) will look blocky and unnatural viewed close up. There were a
`
`number of methods already known for building 3-D meshes at various levels
`
`of detail based on viewpoints, for example, by adding additional vertices as
`
`the viewpoint gets closer to the mesh.
`
`
`15
`
`
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`25. I worked on developing a specific algorithm for building 3-D meshes at
`
`various levels of detail that was intended to be less computationally
`
`intensive than previous methods. I believed that I was successful in
`
`developing a new algorithm for displaying 3-D meshes, such as terrain, and I
`
`described this algorithm in a patent application filed on February 8, 2006,
`
`which eventually issued as US patent number 7,561,156 B2 (“the ‘156
`
`patent”) on July 14, 2009. The work that I invested in developing this
`
`algorithm, reflected in the ‘156 patent, all took place after I returned from
`
`the IDF in 2003, and not before I left for the IDF in 2000. Consequently, the
`
`digital terrain modeling algorithm that I developed is not reflected in the
`
`patents originally filed in 2000 and 2001, because I had not developed it yet.
`
`26. We started introducing my new 3-D digital terrain model into 3DVU
`
`technology toward the end of 2005. For example, a 3DVU press release
`
`dated November 22, 2005, which I accessed via the Internet Archive at
`
`https://web.archive.org/web/20060210012618/http://www.3dvu.com/pdf/Da
`
`ewoo__pr.pdf, announced that the third generation of the 3DVU mapping
`
`platform would include “full landscape elevation.” The same press release
`
`includes a quote from Mr. Levanon stating that “for the first time, navigating
`
`users will view realistic imagery with the elevation of mountains and valleys
`
`
`
`
`16
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`on their mobile devices.” This press release and statement are consistent
`
`with my recollection that the 3-D terrain model was introduced around 2005.
`
`A true and correct copy of this press release, as shown on the Internet
`
`Archive, is attached as Exhibit B.
`
`Discussions with Microsoft
`
`27. I was aware from discussions with Isaac Levanon that Mr. Levanon had
`
`some discussions with Microsoft in 2005 because Mr. Levanon wanted to
`
`sell the company. However, Mr. Levanon did not provide a significant
`
`amount of detail to me about those negotiations. I recall Mr. Levanon
`
`asking me some very high-level technical questions during this time period,
`
`which I understood to have been in response to inquiries from Microsoft.
`
`These questions did not go into any significant technical detail about the
`
`operation of our technology, and only provided a very rough description of
`
`what our software was ideally capable of.
`
`28. At the time that these discussions took place, 3DVU only had two or three
`
`developers working for it, including myself. Another developer named Lion
`
`Burger came to 3DVU during the period when I was serving in the IDF and
`
`left in 2007. 3DVU hired another developer around this time, although I do
`
`not recall if this individual began work before or after the discussions took
`
`
`
`
`17
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`place, and this developer only worked at 3DVU for about a year and a half.
`
`3DVU’s headquarters was listed as Mr. Levanon’s home in in Ra’anana,
`
`Israel, while the actual office that we worked from in working hours was an
`
`apartment in a residential building in Herzelia, Israel. I recall that Mr.
`
`Levanon’s wife and children may have had some formal title within the
`
`company, but I did not see them regularly at the office, with the exception of
`
`Mr. Levanon’s daughter Mor Levanon, who began showing up
`
`approximately around 2007.
`
`29. While Mr. Levanon was in discussions with Microsoft, Mr. Levanon
`
`occasionally sent me questions about 3DVU’s development process which
`
`may have originated from Microsoft, although Mr. Levanon generally sent
`
`me these questions by email in a way that did not indicate where the
`
`question came from. These questions were somewhat awkward and difficult
`
`to answer, because 3DVU at the time did not really have an organized
`
`software development process due to the fact that there were only two or
`
`three developers working there at a time. At one point during this period, I
`
`got on a phone call with someone from Microsoft at Mr. Levanon’s request.
`
`In the phone call I was asked to give a technical overview about the state of
`
`software development in the company and the existing capabilities of our
`
`
`
`
`18
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`software library, although not any technical details of the operation of that
`
`technology. My ability to answer questions during this conversation was
`
`extremely limited because I had almost no experience at the time in spoken
`
`English. I do not believe that either the information that I provided in the
`
`questions that I answered for Mr. Levanon, or the information that I
`
`provided in the phone call with Microsoft, would have been at a sufficient
`
`level of technical detail to provide any useful information about how to re-
`
`create our technology at that point. I am also unaware of any source code or
`
`other similar detailed technical information being provided to Microsoft
`
`during this period.
`
`30. At the time of the negotiations with Microsoft, there were issues with the
`
`3DVU software that would have presented significant challenges if we had
`
`attempted to scale them. For example, our software at the time required
`
`preprocessing of image, terrain, and other geographic data, which we
`
`typically retrieved from commercial sources, before it was ready to load
`
`onto a server. However, our preprocessing software was not yet
`
`parallelized, i.e., set up so that processing could be performed
`
`simultaneously by different processing elements. With large scale maps, the
`
`issue was processing the data in such a way that would avoid conflicts or
`
`
`
`
`19
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`errors along boundaries between adjacent data processed by different
`
`processing elements. We needed to solve this problem in order for the
`
`software to be realistically scaled up to display a worldwide map. This
`
`particular problem took me working alone much of the next two years, into
`
`2007 or 2008. Additionally, the application programmer interface (API) (the
`
`set of definitions, protocols, and tools used for working with our software)
`
`was not very mature or user-friendly, which meant that it would have been
`
`difficult for a programmer from an outside company that acquired us to
`
`write applications to work with our mapping engine and expect them to
`
`work.
`
`Navi2Go
`
`31. 3DVU also worked on a product called Navi2Go in the later years that I
`
`worked at 3DVU. While some of my work on image preprocessing and the
`
`visualization library related to this product, the Navi2Go product was mostly
`
`designed by other developers at 3DVU. Navi2Go was generally designed to
`
`allow users to look up directions and retrieve satellite imagery covering the
`
`area of a route using a web application, then load the route instructions and
`
`imagery onto a PDA or other mobile device. Once the route and imagery
`
`were downloaded, either the web app or the mobile device/PDA could
`
`
`
`
`20
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`display the imagery along the route from a perspective view, much like the
`
`car navigation products. The primary way that Navi2Go was designed to be
`
`used was in this manner, in which the user first downloaded the routing
`
`information and imagery onto a desktop computer, then transferred this
`
`information on to a portable device (for example, using a memory card of
`
`some type or a USB drive).
`
`32. Navi2Go was also primarily written in standard C++ code language. There
`
`was a separate project involving code which was written for Java2ME,
`
`which is an operating environment based on the Java programming language
`
`and was commonly used for small cell phones (also known as “feature
`
`phones”) at the time. However, this project did not include any digital
`
`elevation or terrain modeling features, and would have only displayed
`
`imagery of a region as a “flat” projection, in a similar manner to the 1999-
`
`2000 prototype. Although the Java-based product and the C++ code
`
`libraries generally did not (and could not) share software infrastructure,
`
`some of the operation of this software shared similarities with the C++ code
`
`at a high level, such as the image decompression and the high level structure
`
`
`
`
`21
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`of the rendering software. For example, the image below,2 which to the best
`
`of my recollection is a fair and accurate depiction of the appearance of the
`
`web application user interface at the time we introduced the Navi2Go
`
`application, includes a “save-to-PDA” option in the upper right hand corner
`
`of the screen:
`
`
`33. We developed an algorithm in order to allow the web application to most
`
`efficiently retrieve in advance the imagery that would be needed for a
`
`particular route. After the user’s route was calculated, the algorithm
`
`determined which tiles of the underlying imagery database were intersected
`
`by the routes, and calculated which tiles to download so that higher
`
`
`2 This image was retrieved from a news article about Navi2Go at
`http://bgr.com/2007/12/08/3d-roadmapping-with-navi2go/, which I have also
`attached as Exhibit C.
`
`
`
`
`22
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`resolution imagery would be download for areas closest to the routes and
`
`lower resolution imagery would be downloaded to show areas that would
`
`appear more distant in the background, but would not to be shown close to
`
`the viewing perspective. The amount of high-resolution imagery download
`
`by the software could vary based on the available memory on the portable
`
`device which it would be downloaded to.
`
`34. We described this algorithm in a provisional U.S. patent application (No.
`
`60/880,674) filed in January 2007, and a non-provisional U.S. patent
`
`application (No. 12/015,068) which was published in 2008. The published
`
`application (US 2008/0294332 A1) is attached as Exhibit D. For example,
`
`paragraph 9 of the published application says that “the purpose of this
`
`invention is to provide a solution for the off-line visualization of memory-
`
`consuming datasets such as aerial photography, terrain elevation and 3D
`
`buildings, within the storage and connectivity limitations of today’s
`
`mobile/portable computing platforms as navigation products, such as
`
`Personal Navigation Devices (PND’s).” Additionally, Fig. 4c shows an
`
`example of how the application would download higher-resolution tiles
`
`closest to a route and lower-resolution tiles further away:
`
`
`
`
`23
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`
`35. Some versions of Navi2Go also allowed a user to download the same
`
`information onto a mobile device over a cell phone network in real time;
`
`however, there were some significant problems with this operating mode
`
`which made it generally impractical for most users. First of all, the speed of
`
`wireless networks at the time made the real-time downloading feature
`
`generally very sluggish, choppy, and unsatisfying. Second, the large amount
`
`of data that needed to be downloaded, including imagery, meant that users
`
`who used the real-time downloading feature would incur very large data
`
`usage charges from their cellular carrier. Downloading the data first onto a
`
`
`
`
`24
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`desktop computer, then transferring it to a portable device avoided both of
`
`these problems.
`
`36. Like every other implementation of 3DVU’s technology by 2007, Navi2Go
`
`used variable ratio compression (specifically JPEG) to transmit and store
`
`imagery. As I previously explained, variable compression ratios allowed
`
`more efficient compression than the fixed compression ratio, fixed byte size
`
`tile techniques that 3DVU used in 1999-2000 before I left for the IDF.
`
`Therefore, reverting to the old fixed compression ratio techniques would
`
`have meant that the imagery would require more storage or more bandwidth
`
`than with variable compression, which would have been significantly
`
`disadvantageous either for storing downloaded data on a mobile device or
`
`downloading it in real time.
`
`37. Although I am aware that Navi2Go received some attention from trade
`
`shows and trade papers, my impression was that this program did not
`
`experience significant success. For example, 3DVU never grew from its
`
`headcount of 2-3 developers at any given time from the time that Navi2Go
`
`was released until I left 3DVU, which I would have expected if the software
`
`had done very well commercially.
`
`
`
`
`25
`
`Microsoft, Ex. 1017
`Microsoft v. Bradium, IPR2016-00449
`
`
`
`Compensation for working at 3DVU
`
`38. Toward the end of my time at 3DVU in 2008-2009, I began to notice
`
`irregularities in my pay statements. I noticed that my pay suddenly became
`
`adjusted (without my permission) so that most of my compensation was
`
`characterized as a bonus rather than a salary, which reduced the amount that
`
`3DVU would have needed to pay in various government-required salary
`
`withholdings, which were based on salary only. Additionally, I began to
`
`experience delays receiving my paychecks. My impression at the time was
`
`that 3DVU was struggling to maintain its status as a financially viable
`
`business. I left 3DVU in August 2009 because, in addition to 3DVU’s
`
`evident financial difficulty, it had become apparent to me that the company
`
`was not growing and it did not appear to me that it was likely to grow or
`
`have increased commercial success in the future. I also never received my
`
`final paycheck for working at 3DVU after I told Mr. Levanon tha
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
