`
`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 H (OBD—H) 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. 1014, OBD—H Background—Where’d It Come From?,
`
`http://www.OBDii.com/background.html (under “\X/here’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 ]—1850 in December of 1989. Ex. 1015,
`
`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. 1016, 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
`
`Page 000008
`
`
`
`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-
`
`Page 000009
`
`
`
`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-
`
`Page 000010
`
`
`
`Opinions Regarding the Kosaka Reference
`
`26.
`
`I have read Kosaka and, in my opinion,1 it would have been understood by a
`
`person of ordinary skill in the art as a vehicle telematics system that monitors
`
`vehicle data, such as speed, in order to determine insurance premiums.
`
`In
`
`general, Kosaka discloses that an in—vehicle device monitors vehicle data (e.g.,
`
`speed), which is then used by an “insurance premium determination system” to
`
`evaluate the risk related to the monitored data for purposes of setting insurance
`
`premiums. See EX. 1004, Kosaka at 4, 6-7.
`
`27.
`
`As part of the risk evaluation system, Kosaka discloses storing monitored
`
`vehicle data, such as relative speed, in the memory of the in—vehicle device for
`
`the purpose of analyzing and grouping it as “input value [s] for risk evaluation.”
`
`Id. at 8. A person of ordinary skill in the art would have understood that
`
`selected vehicle data (e.g., speed data, following distance data, etc. relevant to
`
`risk evaluation) is stored in the in—vehicle device memory so it can be used as
`
`these “input values.” Kosaka further explains that these input values are then
`
`output
`
`to a “second fuzzy logic part” as “fuzzy input value[s]
`
`for risk
`
`evaluation.”
`
`1 As noted in paragraph 19, .rz/pm, 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-
`
`Page 000011
`
`
`
`28.
`
`Kosaka also discloses that the system is capable of operating “in real time.”
`
`See, e.g.,
`
`id. at 2 (claim 14). A person of ordinary skill in the art would have
`
`recognized that to operate in real time, the internal and external sensors (566 id.
`
`at 4, Fig. 1) disclosed in Kosaka must also operate in real time. Thus the state
`
`detection elements operate continuously.
`
`29.
`
`However, one skilled in the art would also appreciate that Kosaka indicates that
`
`the “risk evaluation value [that] changes in accordance with the internal state or
`
`external state of the subject being evaluated for risk, which may vary by the
`
`hour or daily.” Id. at 4; we also id. at 7. Since the vehicle data is gathered in real
`
`time, and the risk evaluation and premium calculations may be carried out
`
`hourly or daily, the system necessarily must store the vehicle state data and/ or
`
`intermediate values of risk assessment data based on vehicle state data: “The
`
`fuzzy memory 4 stores risk evaluation values determined when fuzzy logic has
`
`been carried out in advance offline.” Id. at 4. A person of ordinary skill would
`
`have understood that the memory that stores the data would need to be
`
`structured in such a way that different values corresponding to different
`
`operational
`
`times (216.
`
`the real
`
`time samples of vehicle state, or calculated
`
`elements to be used later in risk calculations) would subsequently be selected in
`
`order to carry out risk and premium calculations hourly or daily. See a/50 id. at 6
`
`(“risk evaluation values also may be determined subsequently”). Thus, in my
`
`-12-
`
`Page 000012
`
`
`
`opinion, the in—vehicle device containing the fuzzy memory would have been
`
`understood by a person of ordinary skill in the art to comprise a database.
`
`30.
`
`In addition, as mentioned above, it was common by 1996 for vehicle telematics
`
`systems to respond to an event that sets off a certain trigger. Kosaka, for
`
`example, discloses a telematics system capable of determining when a “set
`
`value” is, for example, exceeded. When this event occurs, Kosaka discloses
`
`that there are particular consequences associated with the trigger event (e.g.,
`
`sending a warning (id. at
`
`A person of ordinary skill would have understood
`
`that this information relating to actions taken in the event a “set value” is
`
`exceeded is necessarily stored separately from other data—e.g., the monitored
`
`speed data and “set values.” Kosaka discloses that the data values being
`
`monitored (e.g., speed and operator control density) are integrated. See, e.g., id.
`
`at Fig. 9 (60, 63). One skilled in the art would have understood that to perform
`
`such an integration would have required storage of these monitored data values.
`
`31.
`
`Kosaka also describes comparing these integrated values to “set values.” See id.
`
`at 7. A person of ordinary skill would have understood that the “set values”
`
`would be stored separately from the integrated values of the monitored data.
`
`See id. at Fig. 9 (60 and 63 (storage of monitored values); 66 (storage of “set
`
`values”)).
`
`-13-
`
`Page 000013
`
`
`
`Executed this 15th day of September, 2012
`
`
`
`Scott Andrews
`
`
`
`At Petaluma CA
`
`-14-
`
`Page 000014