`
`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