`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`§ Att’y Docket Nos.: LMIC-018-802
`§
`§ Customer No. 28120
`§
`
`§ Petitioner: Liberty Mutual
`§ Insurance Company
`§
`
`
`Covered Business Method Review Petition
`of United States Patent No.: 6,064,970
`
`
`
`
`Patent Owner: Progressive Casualty
`
`Insurance Co.
`
`
`
`
`
`
`DECLARATION OF SCOTT ANDREWS
`
`
`I, Scott Andrews, hereby declare under penalty of perjury:
`
`I.
`
`1.
`
`Qualifications
`
`I am currently the Technical Partner of Cogenia Partners, LLC (“Cogenia”), an
`
`independent consulting firm specializing in systems engineering and services
`
`for intelligent transportation systems, safety applications, mobile devices, and
`
`vehicle technologies, which I founded in 2001. I have over 35 years of
`
`experience developing and managing high technology projects, and 20 years of
`
`experience focusing on intelligent transportation systems. My CV is attached at
`
`Ex. 1015.
`
`2.
`
`Cogenia Partner’s clients and partners include the automotive industry, Fortune
`
`100 service enterprises, telecommunications equipment manufacturers, the U.S.
`
`Department of Transportation, state and local transportation entities, university
`
`transportation centers, and startups seeking to enter the broad mobility and
`
`transportation technology and location based services market.
`
`L:iberty Mutual
`Exhibit 1014
`
`3DJH
`
`
`
`3.
`
`In my role at Cogenia Partners, I have consulted with many of the major
`
`carmakers, and leading consumer products and services companies in support
`
`of the creation and delivery of mobile vehicle services.
`
`4.
`
`My previous work experience includes positions at TRW, Inc. and Toyota
`
`Motor Corp.
`
`5.
`
`At Toyota Motor Corporation in Japan, my responsibilities included the
`
`conceptualization and development of multimedia and new technology
`
`products and services for Toyota’s future generations of passenger vehicles in
`
`the United States and Europe. Heavy emphasis was placed on strategy for
`
`information systems, and on development of technical concepts for computing
`
`and Internet oriented systems. Working under the direction of Toyota board
`
`members, I established the Automotive Multimedia Interface Collaboration, a
`
`partnership of the world’s car makers to develop a uniform computing
`
`architecture for vehicle multimedia systems, and led all early technical, planning
`
`and organizational work.
`
`6.
`
`At TRW, Inc., I held a series of positions dealing with emerging transportation
`
`products such as in-vehicle information systems. In 1991 and 1992, while
`
`employed in the Space and Defense sector, I worked with the automotive
`
`division to develop location-based information delivery systems. The first
`
`-2-
`
`3DJH
`
`
`
`system TRW developed used the Teletrac vehicle location system. This used a
`
`“return link” Time Difference of Arrival (TDOA) triangulation scheme (the
`
`system determines the position of the device using signals returned from the
`
`device). This is slightly different from LORAN, which is a “forward link”
`
`TDOA system (the terminal determines its location from the base station
`
`signals), although the two systems are technically similar.
`
`7.
`
`In early 1996, I was in the TRW Automotive Electronics Group and was
`
`working on a variety of automotive electronic systems, including wireless
`
`vehicle location and information systems, such as Mayday and remote
`
`diagnostics, navigation systems, and various driver information and vehicle
`
`safety systems. In April of 1996, I moved to Japan and was employed by
`
`Toyota Motor Corporation and continued to work on a variety of wireless
`
`Intelligent Transportation Systems (ITS).
`
`8.
`
`I have also worked with several law firms in a consulting and/or expert
`
`capacity. My attached CV lists all the matters in which I was involved,
`
`including my testimonial experience. Ex. 1015.
`
`9.
`
`I am also a member of the following professional societies: Society of
`
`Automotive Engineers (SAE), International Institute of Electrical and
`
`Electronic Engineers
`
`(IEEE), IEEE Standards Association, Intelligent
`
`-3-
`
`3DJH
`
`
`
`Transportation Society of America (ITSA), Intelligent Transportation Society
`
`of California (ITSC), Institute of Navigation (ION), and International Counsel
`
`on Systems Engineering (INCOSE).
`
`10. My education includes a B.S. in Electrical Engineering from the University of
`
`California, Irvine, and an M.S. in Electronic Engineering from Stanford
`
`University.
`
`11.
`
`I have been retained on behalf of Petitioner and real party in interest, Liberty
`
`Mutual Insurance Company (“Petitioner” or “Liberty Mutual”), to offer
`
`statements and opinions regarding the understanding of a person of ordinary
`
`skill in the art (discussed below) as it relates to the identified patent assigned to
`
`Progressive Casualty Insurance Company (“Progressive”), as well as other
`
`references presented to me by counsel for Petitioner.
`
`12.
`
`I am being compensated at a rate of $300 per hour for my services, exclusive of
`
`any third party expert service fees. My compensation does not depend on the
`
`outcome of this Business Method Review Petition or the pending litigation
`
`between Petitioner and Progressive in the U.S. District Court for the Northern
`
`District of Ohio.
`
`II. Materials Considered
`
`-4-
`
`3DJH
`
`
`
`13.
`
`In developing my opinions below relating to Progressive’s ‘970 Patent, I have
`
`considered the following materials:
`
`x Progressive’s U.S. Patent No. 6,064,970 (“the ‘970 Patent”) with
`January 10, 2012 Ex Parte Reexamination Certificate (Ex. 1001);
`x U.S. Patent No. 5,465,079 (“Bouchard”) (Ex. 1004);
`x OBD-II
`From?,
`Background—Where’d
`It
`Come
`http://www.OBDii.com/background.html (under “Where’d it come
`from?”) (Ex. 1016);
`
`x Excerpt
`from Shuji Mizutani, Car Electronics, page 250
`(Nippondenso Co. Ltd. 1992) (Ex. 1017); and
`
`x Excerpt from David S. Boehner, Automotive Microcontrollers, in
`Automotive Electronics Handbook, pages 11.24-11.29 (Ronald K.
`Jurgen ed., 1995) (Ex. 1018).
`
`III.
`
`Level of Ordinary Skill for the ‘970 Patent
`
`14.
`
`I have read Progressive’s ‘970 Patent, which I understand was filed on August
`
`17, 1998, issued on May 16, 2000, and claims priority to an application filed on
`
`January 29, 1996. I also understand that the ‘970 Patent went through ex parte
`
`reexamination from November 24, 2010 to January 10, 2012, and that many of
`
`the claims were amended.
`
`15.
`
`The ‘970 Patent purports to cover methods and systems for setting insurance
`
`costs based on vehicle telematics data. See, e.g., Ex. 1001 at Abstract.
`
`Generally, vehicle data is monitored and recorded and the data is then used to
`
`produce a vehicle insurance cost for the period in which monitoring occurred.
`
`See, e.g., claims 1, 4-6, 18.
`
`-5-
`
`3DJH
`
`
`
`16.
`
`I understand that the factors that may be considered in determining the
`
`ordinary level of skill in the art include: (1) the levels of education and
`
`experience of persons working in the field; (2) the types of problems
`
`encountered in the field; and (3) the sophistication of the technology. I
`
`understand that a person of ordinary skill in the art is not a specific real
`
`individual, but rather a hypothetical individual having the qualities reflected by
`
`the factors above.
`
`17.
`
`The field of art relevant to the ‘970 patent is insurance, and more particularly
`
`determining a cost of vehicle insurance based on telematics data. In my
`
`opinion, a person of ordinary skill in the vehicle telematics aspects pertinent to
`
`the ‘970 patent (apart from the insurance cost aspects), as of January 1996,
`
`would have at least a B.S. degree in electrical engineering, computer
`
`engineering, computer science or the equivalent thereof and at least one to two
`
`years of experience with telematics systems for vehicles.
`
`18.
`
`I base this opinion on: the level of technical training I believe is required to
`
`reduce to practice the concepts described in the ‘970 patent and the relevant
`
`prior art; my own experience in hiring and supervising about 30 engineers
`
`engaged in the development of these types of systems by January 1996; my
`
`experience working with developers of these types of systems at Toyota Motor
`
`Corporation in Japan; and my experience working with a technical staff drawn
`
`-6-
`
`3DJH
`
`
`
`from about 20 different automaker and automotive electronic suppliers as a
`
`part of the development of a set of industry telematics standards.
`
`19.
`
`For purposes of this Declaration, unless otherwise noted, my statements and
`
`opinions below, such as those regarding my experience and the understanding
`
`of a person of ordinary skill in the art generally (and specifically related to the
`
`references I consulted herein), reflect the knowledge that existed in the field as
`
`of January 1996.
`
`IV.
`
`State of the Art in the Vehicle Telematics Industry by January 1996
`
`20.
`
`By 1996, several companies had developed vehicle telematics systems that
`
`measured vehicle data, such as speed, acceleration, time of day, etc. These
`
`systems commonly included in-vehicle data monitoring devices that would
`
`monitor the data, store it, and/or transmit it to a remote location outside of the
`
`vehicle. The telematics data could be used for a variety of purposes, including
`
`insurance purposes, such as for setting insurance premiums.
`
`21.
`
`These in-vehicle data monitoring devices were well known in the art and
`
`included a variety of functions. For example, depending on the type or
`
`purpose of an in-vehicle monitoring device, it may have had sensors and other
`
`components within the device (e.g., an accelerometer) able to measure and
`
`collect operating data, or it may have been designed to collect data from
`
`sensors in the vehicle using a hardwire connection or through a vehicle bus. In
`
`-7-
`
`3DJH
`
`
`
`the latter scenario, the device would interface with a vehicle bus (or data bus
`
`performing functions similar to a vehicle bus) that interconnects components
`
`(e.g., sensors) inside a vehicle to collect, for example, speed and acceleration
`
`data from sensors inside the vehicle that monitor these types of data. For
`
`example, the On-Board Diagnostics II (OBD-II) vehicle bus was used in
`
`vehicles since 1994 and has, in fact, been required in passenger vehicles and
`
`light duty trucks since January 1996, as mandated by the Environmental
`
`Protection Agency. Ex. 1016, OBD-II Background—Where’d It Come From?,
`
`http://www.OBDii.com/background.html (under “Where’d it come from?”).
`
`Moreover, multiplex networks, such as vehicle buses, have been in use in
`
`vehicles to connect components in a vehicle since the 1980s. The Society of
`
`Automotive Engineers, for example, released the draft specification for a serial
`
`automotive data bus designated SAE J-1850 in December of 1989. Ex. 1017,
`
`Shuji Mizutani, Car Electronics 250 (Nippondenso Co. Ltd. 1992.)
`
`22.
`
`It was also well known that such in-vehicle monitoring devices would have
`
`memory, including volatile and non-volatile memory. Indeed, storing data in
`
`memory has been an integral part of any data processing system (including a
`
`telematics system) since long before 1996. Ex. 1018, David S. Boehner,
`
`Automotive Microcontrollers, in Automotive Electronics Handbook 11.24-
`
`11.29 (Ronald K. Jurgen, ed., 1995). Further, the idea of storing data in a
`
`-8-
`
`3DJH
`
`
`
`memory/storage system in an organized fashion that allows access to the
`
`stored data through, e.g., searching, was well known in the art well before 1996.
`
`These database capabilities – including retrieving and relating stored data –
`
`were also understood at the time to be fundamental to analyzing vehicle
`
`telematics data. In particular, vehicle telematics analysis requires evaluation of
`
`changing data points over time (e.g., changes in speed or acceleration). Thus, in
`
`order to retrieve varying data points to manipulate them, analyze them,
`
`compare them, etc., they must be stored in a way that would make them
`
`available for retrieval and analysis in a meaningful way, that is, in relation to
`
`other data collected at the same time or under similar circumstances.
`
`23. Many different ways of transmitting vehicle telematics data in such telematics
`
`systems (from an in-vehicle device) were also known at the time. For example,
`
`wireless transmitters or receivers, configured to transmit and/or receive data
`
`between a vehicle or a device installed in a vehicle and a remote server by way
`
`of a distributed network, were well known prior to 1996. A wireless transmitter
`
`or receiver would have been a known component of a telematics device or
`
`server, or a stand-alone device that interfaces with a telematics device or server.
`
`24.
`
`Indeed, it was well known in the art prior to 1996 that wireless transmitters or
`
`receivers could be configured to transmit and receive communication between
`
`a vehicle or driver and a third-party, such as a dispatcher or roadside assistance
`
`-9-
`
`3DJH
`
`
`
`operator. For example, it was well understood prior to 1996 that such a
`
`wireless transmitter or receiver would be capable of sending an alert, such as a
`
`textual or aural message, to a third-party when a certain vehicle event or
`
`emergency occurs—e.g., when the vehicle exceeds a certain speed limit or
`
`acceleration or deceleration value (such as when a crash occurs), travels outside
`
`a designated area, or when the driver is locked out of the car.
`
`25.
`
`Back-end aspects of these known telematics systems would have included
`
`computer networks comprising, for example, server(s), processor(s), and
`
`database(s) for retaining, analyzing, and processing the telematics data. Thus,
`
`in addition to an in-vehicle device with memory in which data points are
`
`associated and retrievable, a remote database to store the telematics data after
`
`transmission was also well known in the art. Among other things, such a
`
`database for a telematics system would have made the data available in a
`
`meaningful way for processing, would have made the data retrievable, and
`
`would have facilitated analysis of the data in pertinent groupings for purposes
`
`of, e.g., insurance rating.
`
`-10-
`
`3DJH
`
`
`
`V.
`
`26.
`
`Opinions Regarding the Bouchard Reference
`
`I have read the Bouchard reference and, in my opinion,1 it would have been
`
`understood by a person of ordinary skill in the art to disclose a method and
`
`system for monitoring vehicle sensors to obtain various data elements and
`
`determine the operational status of a vehicle. See, e.g., Ex. 1004 at 9:26-47; 24:9-
`
`16; 30:19-22. In particular, Bouchard teaches using a combination of
`
`monitored data elements to evaluate the safety of a driver’s performance in
`
`real-time by comparing the driver’s current performance to normal driving
`
`standards and the driver’s past performance. Id. at 5:13-29.
`
`27.
`
`Bouchard discloses a method of collecting information from vehicle sensors
`
`representative of operator or vehicle driving characteristics, and storing such
`
`vehicle data in an event recording apparatus (“ERA”). The system “provides a
`
`removable, externally readable, non-volatile solid-state memory event recording
`
`apparatus (ERA) that records selectable vehicle performance, operational
`
`status, and/or environment information.” Id. at 5:53-57. Further the “ERA
`
`system is configured to store a wide variety of vehicle information”—including
`
`a “record of th[e] driver’s driving history and performance.” Id. at 5:66-6:8. In
`
`order to store a driving history and performance data, it necessarily would have
`
`1 Again, as noted in paragraph 19, supra, the discussions herein all present my opinion
`of what a person of ordinary skill in the art would have understood as of January
`1996.
`
`-11-
`
`3DJH
`
`
`
`required indexing the various parameters comprising performance data by time.
`
`In other words, because the ERA is a non-volatile memory capable of storing a
`
`wide variety of data that is retrievable and “selectable,” a person of ordinary
`
`skill would have understood that, to make such selections, the wide variety of
`
`data stored in the ERA would be indexed in such a way that portions of the
`
`data could be accessed separately from others, based on characteristics of the
`
`data itself. See, e.g., id. at 5:53-6:8, Fig. 18. Therefore, in my opinion, a person
`
`of ordinary skill in the art would have understood the ERA disclosed by
`
`Bouchard is a database.
`
`28.
`
`Finally, Bouchard discloses that recent driver history data—i.e. the vehicle
`
`operating data—is monitored and stored. See, e.g., 31:36-37, Fig. 18 (step 1807).
`
`As illustrated in Figure 18, the driver data is grouped into categories and
`
`classes. See id. at Fig. 18 (1801, 1802, 1803). This recent driver history data is
`
`compared to a generated “profile” of the driver’s past driving behavior. See id.
`
`at 30:3-6, 30:29-58, Fig. 18 (step 1803). As further shown in Figure 18, a
`
`person of ordinary skill would have understood that the “profile” (1803) is
`
`stored and maintained separately from the recent driver history (1807). A
`
`person of ordinary skill also would have understood that the outcome of the
`
`comparison (step 1806) is stored locally in order to execute a “driver alert,”
`
`-12-
`
`3DJH
`
`
`
`“dispatcher alert,” or “vehicle shut-down,” and is also stored in a separate
`
`“event recorder” memory. See, e.g., Fig. 18 (step 1808).
`
`
`
`Executed this 15th day of September, 2012
`
`
`
`
`
`
`
`
`
`
`
`
`
`Petaluma, CA
`
`
`
`
`at
`
`
`
`
`
`
`
`
`Scott Andrews
`
`
`
`-13-
`
`3DJH
`
`