throbber
DECLARATION OF SCOTT ANDREWS
`
`I, Scott Andrews, declare as follows:
`
`I hold a B.Sc. degree in Electrical Engineering from University of California–
`
`
`
`1.
`
`Irvine and a M.Sc. degree in Electronic Engineering from Stanford University. In
`
`various positions at, among others, TRW and Toyota, I have been responsible for
`
`research and development projects relating to, among others, numerous vehicle
`
`navigation systems, information systems, and user interface systems. My qualifications
`
`are further set forth in my curriculum vitae (Exhibit A). I have been retained by
`
`Volkswagen Group of America, Inc. in connection with its petition for inter partes
`
`review of U.S. Patent No. 7,917,285 (“the ’285 patent”). I have over 25 years of
`
`experience in fields relevant to the ’285 patent, including vehicle telecommunications
`
`systems, vehicle navigation systems, and telematics-aided vehicle navigation systems.
`
`2.
`
`I have reviewed the ’285 patent, as well as its prosecution history and the prior
`
`art cited during its prosecution, including U.S. Patent Application Publication No.
`
`2004/02284849
`
`(“Ishibashi”) and U.S. Patent Application Publication No.
`
`2004/0064245 (“Knockeart”). I have also reviewed U.S. Patent No. 6,526,335
`
`(“Treyz”), European Patent Application Publication No. 1 302 751 (“Demir”), U.S.
`
`Patent Application Publication No. 2003/0043019 (“Tanaka”), the Richard Lind et al.
`
`publication, The Network Vehicle – A Glimpse into the Future of Mobile Multi-Media, SAE
`
`Brasil 98, VII International Mobility Technology Conference & Exhibit (“Lind”), and
`
`U.S. Patent No. 7,386,393 (“Zabel”).
`
`VWGoA - Ex. 1002
`Volkswagen Group of America, Inc. Petitioner
`Rothschild Location Technologies, LLC, Patent Owner
`Case No. IPR2015-00793
`
`1
`
`

`
`
`
`The ’285 Patent
`
`3.
`
`The ’285 patent describes remotely entering addresses into GPS devices. A user
`
`enters a location into a web browser in a computer 306, and the computer 306
`
`transmits the location to a server 304. Col. 9, l. 67–col 10 20. The server 304 then
`
`resolves the address and sends the resolved information to the GPS device 100. Col.
`
`10, ll. 34–38. The GPS device uses the information to provide route guidance. Col. 10,
`
`ll. 38–49. To identify both the user and the user’s GPS device, the system described in
`
`the ’285 patent uses an Internet cookie and a database of GPS device transmission
`
`information. The user’s computer transmits an Internet cookie to the server to
`
`identify the user, and the server utilizes a database to identify a telephone number or
`
`IP address for use in transmitting information to the GPS device 100. Col. 10, ll. 21–
`
`33.
`
`4.
`
`According to my understanding of the prosecution of the ’285 patent, claim 1
`
`was granted on an application claim, i.e., application claim 25, which described a
`
`system for entering location information into a positional information device
`
`including a server that is configured to receive a request for a location, to determine
`
`coordinates of the location, and to transmit the coordinates to the positional
`
`information device, as follows:
`
`25. A system for entering location information into a positional information
`device, the system comprising:
`
`2
`
`

`
`a server configured to receive a request for at least one location, determine
`coordinates of the least one requested location and to transmit the determined
`coordinates to the device;
`the positional information device including
`a locational information module for determining location information of the
`device;
`a communication module for receiving coordinates of the at least one location
`from the server;
`a processing module configured to receive the coordinates from the
`communication module and determine route guidance based on the location of
`the device and the received coordinates; and
`a display module for displaying the route guidance; and
`a communications network for coupling the positional information device to
`the server.
`After being rejected as anticipated by Ishibashi, this claim was amended to
`
`5.
`
`describe “remotely” entering location information and to change “coordinates” to
`
`“address, ” as follows:
`
`25. A system for remotely entering location information into a
`positional information device, the system comprising:
`a server configured to receive a request for an address of at least one
`location not already stored in the positional information device, to
`determine coordinates the address of the least one requested location
`and to transmit the determined coordinates address to the positional
`information device;
`the positional information device including
`
`3
`
`

`
`a locational information module for determining location information
`of the positional information device;
`a communication module for receiving the determined coordinates
`address of the at least one location from the server;
`the determined
`a processing module configured
`to receive
`coordinates address from the communication module and determine
`route guidance based on the location of the positional information
`device and the received determined coordinates address; and
`a display module for displaying the route guidance; and
`a communications network for coupling the positional information
`device to the server.
`After again being rejected, as anticipated by Knockeart, this claim was further
`
`6.
`
`amended to describe that “the request is received from a remote computer with a first
`
`identifier and the server being configured to determine a second identifier for
`
`identifying the positional information device based on the received first identifier,” as
`
`follows:
`
`25. A system for remotely entering location information into a
`positional information device, the system comprising:
`a server configured to receive a request for an address of at least one
`location not already stored in the positional information device, to
`determine the address of the least one location and to transmit the
`determined address to the positional information device,
`wherein the request is received from a remote computer with a first
`identifier and the server being configured to determine a second
`identifier for identifying the positional information device based on the
`received first identifier;
`
`4
`
`

`
`the positional information device including
`a locational information module for determining location information
`of the positional information device;
`a communication module for receiving the determined address of the
`at least one location from the server;
`a processing module configured to receive the determined address
`from the communication module and determine route guidance based
`on the location of the positional information device and the determined
`address; and
`a display module for displaying the route guidance; and
`a communications network for coupling the positional information
`device to the server.
`According to the Office Action dated October 13, 2010, the Examiner
`
`7.
`
`concluded that Knockeart disclosed all of the limitations of application claim 25,
`
`except for the limitation that “the server being configured to determine a second
`
`identifier for identifying the positional information device based on the received first
`
`identifier.” As discussed below, however, this limitation of claim 1 of the ’285 patent,
`
`as well as the remaining limitations of claims 1 through 12 of the ’285 patent, are
`
`described in the prior art. In my opinion, a person of ordinary skill in the art, at the
`
`time of the filing of the application for the ’285 patent, would have found the systems
`
`described in claims 1 through 12 obvious in view of the prior art.
`
`
`
`5
`
`

`
`The Combination of Knockeart and Treyz – Claims 1 to 5, 9, and 10
`
`8.
`
`In my opinion, it would have been obvious to combine the teachings of
`
`Knockeart and Treyz, as discussed below, to achieve the system claimed in the ’285
`
`patent. The combination of Knockeart and Treyz describes all of the limitations of
`
`claims 1 through 5, 9, and 10 of the ’285 patent, including the limitation which was
`
`the basis for the allowance of the ’285 patent, i.e., “wherein the request is received
`
`from a remote computer with a first identifier and the server being configured to
`
`determine a second identifier for identifying the position information device based on
`
`the received first identifier.”
`
`9.
`
`Knockeart, assigned to Siemens Automotive Corp., published on April 1, 2004.
`
`Knockeart describes a vehicle information system including an in-vehicle system 105
`
`in communication with a centralized server 125, used to provide route planning.
`
`Abstract; ¶¶ 9, 73. The operator of the vehicle inputs a desired destination into the in-
`
`vehicle system 105, which uploads the desired destination to the server system 125.
`
`The server system determines a route plan and sends the plan to the in-vehicle system
`
`105, which performs route guidance. ¶ 74.
`
`10.
`
`In-vehicle system 105 includes onboard computer 210, processor 212, GPS
`
`antenna 253, GPS receiver 252, cellular transceiver 254, and display 242. The vehicle
`
`operator enters a desired destination into the in-vehicle system, which sends the
`
`information, along with the current location of the vehicle, to the server system 125
`
`over cellular telephone network 350 and PSTN 340. ¶¶ 113–127. The server system
`
`6
`
`

`
`determines a route from the current location of the vehicle to the desired destination,
`
`and transmits that route information to the vehicle along with spot maps of the
`
`current location and destination. The in-vehicle system 105 uses the information to
`
`provide route guidance. ¶¶ 73–74, 183–185.
`
`11. The server system 125 uses the desired destination input by the vehicle
`
`operator to validate the destination, or determine the street address of the desired
`
`destination. For example, as described by Knockeart, the server system 125 is used to
`
`validate a desired destination entered by the vehicle operator if the destination is
`
`outside of the geographic range of data stored in the in-vehicle system. ¶ 239. As a
`
`further example, the server system 125 executes a navigation application 512 to
`
`determine the address of a desired destination by comparing an entered telephone
`
`number to a yellow pages database 520. ¶¶ 168–169, 236. Knockeart recognizes that
`
`the in-vehicle database may not include all possible yellow page listings and that only
`
`categories of listings may be included in the in-vehicle database. ¶ 230. An operator is
`
`presented with a list of categories and may select a category from the list. Id. Once the
`
`operator selects a yellow page category, a communication session between the in-
`
`vehicle system and the server system is established, and the specific listings, i.e., street
`
`addresses, in the selected category are downloaded from the server system to the in-
`
`vehicle system, and the operator can select a particular destination from the
`
`downloaded list. ¶ 231. Furthermore, in implementing a “reverse” telephone
`
`directory, Knockeart describes that the “operator can specify a destination by
`
`7
`
`

`
`specifying the telephone number of the destination” and that the “server system
`
`receives the telephone number and looks in [sic] up in a ‘reverse’ telephone directory
`
`to determine the street address of the destination.” ¶ 236.
`
`12. Treyz describes a networked personal computer for a vehicle. The automobile
`
`computer system communicates over the Internet using remote wireless links, and
`
`may be controlled by a user using a service provider. Col. 2, ll. 5–8, 44–45; Col. 19, ll.
`
`33–45; Fig. 13.
`
`
`13. Treyz describes numerous functions of the automobile personal computer 14.
`
`Several of those functions require a system for verifying a user identity before
`
`providing access to a user. A user registers user identification information (a first
`
`identifier), such as a name, password, or personal identification number (PIN). Col.
`
`8
`
`

`
`30, ll. 25–32, 54–60. The user may then also register an automobile personal computer
`
`to be associated with that user’s identification information. Automobile personal
`
`computers are identified by an identification number or a communications address (a
`
`second identifier). Col. 42, ll. 10–25. In addition, a manufacturer may maintain a
`
`database of the identification information of automobile personal computers and their
`
`users. Col. 32, ll. 28–54.
`
`14. Once the user identification information and automobile personal computer
`
`identification number or communications address are registered with the server, the
`
`information can be used to determine the automobile personal computer associated
`
`with a particular user. For example, if a user logs in to a service provider server to
`
`remotely control the automobile personal computer, the user’s identification
`
`information will allow the server to identify the corresponding automobile personal
`
`computer according to its identification number or communications address. Col. 42,
`
`ll. 38–44. As another example, if a user wants to locate a vehicle, a user may provide
`
`user identification information to a kiosk, which will contact the database to
`
`determine the communications address of the associated automobile personal
`
`computer, and will allow the system to contact the automobile personal computer to
`
`determine its location. Col. 32, ll. 28–66. Further still, a user can request the street
`
`address associated with the current location of the vehicle, and the system will
`
`perform a database look-up operation in a remote database to determine the street
`
`address and transmit the street address to the user. Col. 44, ll. 27–42.
`
`9
`
`

`
`15. Treyz therefore describes the claimed server (service provider server or third
`
`party database), receiving a request from a remote computer (home device or kiosk)
`
`including a first identifier (user identification information, e.g., name, PIN, or
`
`password), determining a second identifier for identifying a position information
`
`device (automobile personal computer 14) based on the received first identifier
`
`(determining
`
`the automobile personal computer
`
`identification number or
`
`communications address), and transmitting information to the positional information
`
`device (control commands or request for location).
`
`16.
`
`In my opinion, it would have been obvious to combine the teachings of
`
`Knockeart and Treyz to achieve the systems claimed in the ’285 patent.
`
`17.
`
`For example, both Knockeart and Treyz describe systems that transmit
`
`requests from a remote computer to a server requesting information, and the server
`
`transmitting the requested information to a navigation unit in a vehicle. More
`
`specifically, Knockeart describes that a server determines an address of a location in
`
`response to the user’s request, and transmits the address information to the vehicle
`
`computer system. In the system described by Knockeart, the in-vehicle system guides
`
`the operator along a calculated route to the determined address and also replans a new
`
`route to the destination if the vehicle deviates from a planned route. Treyz specifically
`
`describes transmitting a request from a remote computer, along with a first identifier,
`
`to the server, and the server using the first identifier to determine a second identifier
`
`for
`
`identifying the positional
`
`information device to receive the determined
`
`10
`
`

`
`information from the server, by describing user identification information to match an
`
`associated automobile personal computer.
`
`18. According to Treyz, the first and second identifiers are provided for security
`
`purposes in remotely communicating with a vehicle, including verifying a user’s
`
`identity. See, e.g., col. 2, ll. 44–47, col. 30, l. 25–col. 31, l. 15.
`
`19. At the time that the ’285 patent was filed, it would have been obvious to
`
`modify the vehicle information system taught by Knockeart to include the automobile
`
`remote control and user authentication system taught by Treyz for greater
`
`functionality in the automobile computer system, and for security purposes in
`
`remotely communicating with a vehicle, including verifying a user’s identity, as taught
`
`by Treyz.
`
`20. Additionally, several years before the filing of the ’285 patent, as well as
`
`contemporaneously to the filing of the ’285 patent, other companies developed
`
`vehicles with networked connectivity, allowing users to interact with their vehicles
`
`remotely. This industry activity further supports my opinion that the system claimed
`
`in the ’285 patent would have been obvious to a person of ordinary skill in the art,
`
`and that it would have been obvious to combine the teachings of Knockeart and
`
`Treyz.
`
`21.
`
`For example, as described by Lind, the Network Vehicle was developed by a
`
`group of companies including Delphi Delco Electronics Systems, IBM, Netscape
`
`Communication, and Sun Microsystems. The Network Vehicle developers loaded
`
`11
`
`

`
`several computing and communications devices into a vehicle, to show that the
`
`technology could successfully be used in a variety of ways. The Network Vehicle
`
`included a roof-mounted antenna to provide a satellite connection to the Internet. p.
`
`2. The system associated with the Network Vehicle included an off-board network
`
`architecture, including a home/office computer and an IBM web server, among
`
`others. p. 2. As described by Lind, the Network Vehicle developers provided a web
`
`site for users of the Network Vehicle to remotely access the computing systems
`
`located in the vehicle. The vehicle web site allowed users to “plan trips on the vehicle
`
`web site, then download them to your vehicle.” p. 4.
`
`22. The Lind article also describes systems in which a user can remotely enter
`
`information into a positional information device in a vehicle. Lind states that the
`
`Network Vehicle was demonstrated at the Computer Dealer’s Exhibits (COMDEX
`
`‘97) in Las Vegas, Nevada, on November 17–19, 1997, nine years before the filing of
`
`the ’285 patent. At this demonstration, the presenters of the Network Vehicle
`
`(Delphi, IBM, Netscape, and Sun Microsystems) presented the vehicle website that is
`
`described by Lind, as noted above.
`
`23.
`
`I have reviewed screenshots of the Network Vehicle web site, and attached
`
`those screenshots as Exhibit B. I acquired these screenshots pursuant to my work as
`
`an expert witness engaged by Volkswagen Group of America, Inc. in connection with
`
`Affinity Labs of Texas, LLC v. BMW North America, LLC, et al., Case No. 9:08-cv-00164
`
`(E.D. Tex.).
`
`12
`
`

`
`24. Moreover, in 1997, I personally attended a demonstration of the Network
`
`Vehicle, conducted by Delphi at a Delphi supplier exhibition at Toyota’s headquarters
`
`in Toyota City, Japan. At that event, the developers of the Network Vehicle
`
`demonstrated its features to me, and explained the system operation.
`
`25. Referring to Exhibit B, as illustrated in, e.g., the “Member Home” page, once a
`
`user logged in to the web site as an owner of the Network Vehicle, the Vehicle ID
`
`(“J3792X04128”) was displayed. The next page, the “Travel Itinerary” web page,
`
`shows entry of origin and destination cities, route, origin, and destination maps that
`
`can be selected and downloaded to the Network Vehicle identified by the Vehicle ID.
`
`The Network Vehicle, and its associated off-board network architecture and web site,
`
`therefore demonstrate that it would have been obvious to provide a first identifier (a
`
`user’s log-in information) to determine a second identifier identifying the positional
`
`information device (the Vehicle ID).
`
`26. As a further example, Zabel describes BMW’s “Google Send to Car” project, in
`
`which destination information could be transmitted to a vehicle over a network. Using
`
`a remote computer, a user could perform online searches for destination information,
`
`and have the resulting information sent to their vehicle. The server 150 compares the
`
`user’s identification information to a vehicle database 170 to identify an associated
`
`vehicle and the communication information of the in-vehicle navigation system 140.
`
`Once the vehicle and its communication information has been identified, the server
`
`150 sends the requested information to that in-vehicle navigation system 140. Col. 1,
`
`13
`
`

`
`ll. 62–66; col. 2, l. 53–col. 3, l. 8; col. 3, l. 57–col. 4, l. 10. In my opinion, Zabel also
`
`demonstrates the obviousness of the system claimed in the ’285 patent.
`
`27. The use of Internet cookies to identify a user of a web browser to a server was
`
`well known in 2006, when the ’285 patent was filed. For example, in 1999, seven years
`
`before the ’285 patent was filed, IBM received a patent describing web server user
`
`authentication using Internet cookies, U.S. Patent No. 5,875,296.
`
`It is a further object of the invention to provide a distributed file system
`authentication scheme for Web browsing that only requires passing of a
`user id and password when the user initially logs in to the file system
`through a Web server. On subsequent requests, a secret handle stored in
`a ‘cookie’ is passed from the Web browser to the Web server.
`
`Col. 2, ll. 29–34;
`
`In response to receipt by the Web server of a user id and password from
`the Web client, a login protocol is executed with the security service. If
`the user can be authenticated, a credential is stored in an in-memory
`credential database of credentials associated with authenticated users.
`The Web server then returns to the Web client a persistent client state
`object having a unique identifier therein. This object, sometimes referred
`to as a cookie, is then used to enable the Web client to browse Web
`documents in the distributed file system. In particular, when the Web
`client desires to make a subsequent request to the distributed file system,
`the persistent client state object including the identifier is used in lieu of
`the user’s id and password, which makes the session much more secure.
`
`
`Col. 2, l. 66–col. 3, l. 12.
`
`14
`
`

`
`28. The use of IP addresses to identify a device for sending or receiving
`
`information over the Internet was also well known in 2006, when the ’285 patent was
`
`filed. For example, in 2003, IBM filed a patent application describing the use of
`
`Internet Protocol (“IP”) addresses, which eventually issued as U.S. Patent No.
`
`7,114,006.
`
`In the most widely installed level of the Internet Protocol (“IP”) today,
`an IP address is a 32-bit number that identifies each sender or receiver
`of information that is sent in packets across the Internet. When a user
`requests an HTML page, the Internet Protocol part of TCP/IP includes
`the user's IP address in the message (actually, in each of the packets if
`more than one is required) and sends it to the IP address that is obtained
`by looking up the domain name in the Uniform Resource Locator
`(“URL”) requested. At the other end, the recipient can see the IP
`address of the Web page requestor and can respond by sending another
`message using the IP address it received.
`
`Col. 1, ll. 56–67.
`
`
`
`The Combination of Knockeart, Treyz, and Demir – Claims 6 to 8
`
`29.
`
`In my opinion, it would have been obvious to combine the teachings of
`
`Knockeart, Treyz, and Demir, as discussed below, to achieve the system described in
`
`claims 6 through 8 of the ’285 patent. As described above, the combination of
`
`Knockeart and Treyz describes all of the limitations of claim 1 of the ’285 patent,
`
`including the limitation which was the basis for the allowance of the ’285 patent, i.e.,
`
`15
`
`

`
`“wherein the request is received from a remote computer with a first identifier and the
`
`server being configured to determine a second identifier for identifying the position
`
`information device based on the received first identifier.” Demir describes the
`
`limitations of claims 6 through 8, and it would have been obvious to combine the
`
`teachings of Demir with the combination of Knockeart and Treyz.
`
`30. Demir describes another system for entering destination information into a
`
`navigation unit of a vehicle. The user transmits an address to a server (service control
`
`point 6), which generates destination information suitable for the on-vehicle
`
`navigation system associated with the transmitted address. Abstract. As relevant to
`
`claim 6 of the ’285 patent, the service control point 6 assigns geographical coordinates
`
`to the address before transmitting that information to the operating unit 3 in the
`
`navigation system of a vehicle. Abstract, ¶ 41 (“In a second step, destination
`
`recognition means 7 assigns geographical coordinates to a specified and clearly
`
`identified destination address.”). As relevant to claims 7 and 8, a user specifies a
`
`destination address according to conventional address format, including the name or
`
`street. ¶ 9 (“In one advantageous specific embodiment, the destination address is
`
`specified by the user as the complete, conventional address, for instance, in the
`
`format: first name, last name, street name, house number, place of residence.”).
`
`31. At the time that the ’285 patent was filed, it would have been obvious to
`
`combine the teachings of Knockeart and Treyz with the teachings of Demir for a
`
`system for specifying a destination address. Demir teaches that the system for
`
`16
`
`

`
`specifying a destination address provides “a convenient and accurately addressed
`
`destination selection of the navigation system at all times,” and a “simplification of
`
`the destination selection [which] increases the readiness for using the navigation
`
`system, and thus enables a convenient, reliable and stress-free trip to the travel
`
`destination.” Demir, ¶ 10. For at least these reasons, it is my opinion that a person of
`
`ordinary skill in the art, at the time that the ’285 patent was filed, would have found it
`
`obvious to combine the teachings of Demir with the teachings of Knockeart and
`
`Treyz.
`
`
`
`The Combination of Knockeart, Treyz, and Tanaka – Claims 11 and 12
`
`32.
`
`In my opinion, it would have been obvious to combine the teachings of
`
`Knockeart, Treyz, and Tanaka, as discussed below, to achieve the system described in
`
`claims 11 and 12 of the ’285 patent. As described above, the combination of
`
`Knockeart and Treyz describes all of the limitations of claim 1 of the ’285 patent,
`
`including the limitation which was the basis for the allowance of the ’285 patent, i.e.,
`
`“wherein the request is received from a remote computer with a first identifier and the
`
`server being configured to determine a second identifier for identifying the position
`
`information device based on the received first identifier.” Tanaka describes the
`
`limitations of claims 11 and 12, and it would have been obvious to combine the
`
`teachings of Tanaka with the combination of Knockeart and Treyz.
`
`17
`
`

`
`33. Knockeart describes downloading “spot maps as small graphs around the
`
`starting location or the selected maneuver points” from the server system to the in-
`
`vehicle system. ¶ 257.
`
`34. Tanaka, assigned to Hitachi, Ltd., published on March 6, 2003. Tanaka
`
`describes a system for remotely controlling on-vehicle devices, such as a navigation
`
`apparatus, allowing a user to enter a request for information associated with a
`
`particular location, e.g., an address, into a remote computer (stationary computer
`
`terminal 301 or mobile device 302) as control content, and to transmit the request to a
`
`server (service center 10) with a user identifier. ¶¶ 38, 42–44, 57, 60; Fig. 1. The server
`
`(service center 10) stores the user identifier and the control content in control
`
`information database 105, and produces “control information” used to cause an on-
`
`vehicle navigation apparatus to execute, e.g., navigation. ¶¶ 44–47.
`
`
`
`18
`
`

`
`35. As described by Tanaka, a vehicle transmits the user identifier to the server,
`
`and the server responds with all of the control information stored on the server
`
`associated with that user identification. ¶¶ 96–100. The control information may
`
`include commands for the navigation apparatus of the on-vehicle equipment 20, so
`
`that route guidance may be processed and displayed. ¶¶ 68–72.
`
`36. Tanaka therefore describes the claimed server (service center 10), receiving a
`
`request from a remote computer (terminals 301 or 302), determining an address for a
`
`location (searching point information database 108) and transmitting the determined
`
`address to a positional information device (on-vehicle navigation apparatus 20). The
`
`request includes a first identifier (ID information), and the server determines which
`
`position information device to send the information when the user later submits the
`
`ID information from the on-vehicle equipment.
`
`37. Tanaka describes a map information request from the on-vehicle equipment 20
`
`to map information database 106 of service center 10. ¶ 58. If the necessary map
`
`information is not included in the on-vehicle equipment’s map information database
`
`205, the on-vehicle equipment 20 requests the map information from the map
`
`information database 106, and the map information database 106 transmits the
`
`requested map information to the on-vehicle equipment 20. ¶ 110.
`
`38. At the time that the ’285 patent was filed, it would have been obvious to
`
`combine the teachings of Knockeart and Treyz with the teachings of Tanaka for
`
`acquiring map information from a database on a server. The prior art teaches that
`
`19
`
`

`
`system for acquiring map information from remote databases advantageously avoid
`
`requiring an on-vehicle database to store large quantities of map information. See, e.g.,
`
`Tanaka, ¶ 110; Knockeart, ¶ 11 (“An advantage of the invention is that the vehicle
`
`does not have to have a prestored map to plan a route to a destination.”); Demir, ¶ 11
`
`(“it is possible to access a particularly voluminous and current data base . . . no
`
`memory is required in the motor vehicle for the complete storage of all destination
`
`addresses of the navigation system.”). For at least these reasons, it is my opinion that
`
`a person of ordinary skill in the art, at the time that the ’285 patent was filed, would
`
`have found it obvious to combine the teachings of Tanaka with the teachings of
`
`Knockeart and Treyz.
`
`I declare that all statements made herein of my own knowledge are true and
`
`
`
`that all statements made on information and belief are believed to be true, and further
`
`that these statements were made with the knowledge that willful false statements and
`
`the like so made are punishable by fine or imprisonment, or both, under §1001 of
`
`Title 18 of the United States Code.
`
`
`
`Dated: 1/21/2014
`
`
`
`
`
`
`
`
`Scott Andrews
`
`
`
`
`
`
`
`
`
`20
`
`

`
`
`
`
`
`
`
`Exhibit
`
`Exhibit
`A
`
`21
`
`

`
`
`(650) 279-0242
`
`
`Scott Andrews
`
`915 Western Ave.
`Petaluma, CA 94952
`
`Summary
`Creative, energetic, and innovative internationally recognized executive experienced in
`general management, systems engineering, advanced product development, advanced
`technology, business development, strategic planning, and program management
`
` •
`
` Vehicle Electrical/Electronics Systems
`• Vehicle Information Systems
`• Communications Systems
`• ITS and Related Industries
`• Program and Project Management
`
`
`• Enterprise Software
`• Multimedia/Internet Computing
`• Vehicle Safety and Control Systems
`• Spacecraft Electronics
`• Mobile Information Technology
`
`Experience
`
`Consultant
`12/2001-Present
`Systems engineering, business development and technical strategy consulting supporting
`automotive and information technology.
`Current Engagements:
`• Technical consultant to ARINC for connected vehicle application systems
`engineering and development of high precision connected vehicle test bed for
`FHWA (Federal High Way Admin.)
`• Technical consultant to Booz Allen for connected vehicle performance measures
`development project for NHTSA (National Highway Traffic Safety Admin.)
`• Technical consultant to Booz Allen for connected vehicle standards for FHWA
`• Technical consultant to American Association of State Highway Transportation
`Officials (AASHTO) for connected vehicle deployment analysis and strategy
`• Technical consultant to Michigan State DOT (Enterprise Pooled Fund) to develop
`a system architecture and deployment strategy for Rural ITS
`• Expert witness for Toyota in a case brought by American Vehicular Sciences
`(AVS)
`• Expert witness for Toyota in a patent case brought by Affinity Labs
`• Expert Witness for TomTom in a patent case brought by AVS
`• Expert witness for Liberty Mutual, Geico and Hartford in a patent case brought by
`Progressive Insurance
`• Exp

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket