DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 22, 2025 has been entered.
Status of Claims
This action is in reply to the response filed on December 22, 2025.
Claims 1-20 are currently pending and have been examined.
This action is made Non-FINAL.
The examiner would like to note that this application is now being handled by examiner Christine Huynh.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on December 23, 2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant's arguments filed December 22, 2025 have been fully considered but they are not persuasive. With respect to the 35 U.S.C. 101 rejection, applicants argue in pages 1-2 that the amended claims are not directed towards an abstract idea because the claim elements integrate the abstract idea into a practical application, however, the examiner respectfully disagrees, because even if the limitations are “inherently technological” (see page 2), does not mean that the limitations cannot be performed in the human mind. For example, the limitations of “determining driving attributes based on the telematics data”, “combining and denormalizing the driving attributes by associating the driving attributes together based at least in part on matching corresponding timestamps to create denormalized attributes”, and “aggregating the denormalized attributes for a time period to create aggregated attributes” can be done mentally by a person by observing the given telematics data and making a determination of the driving attributes, organize the given data based on the driving attributes into a table, and combining and summarizing the given data. While the applicant argues that because the tasks are done in “substantially real-time” and therefore represent a “significant enhancement to the operation of the computing system” (see page 2), that the claims are not directed to a 101 abstract concept. However, making a determination, organizing, and summarizing data values are mathematical calculations that can be done by a person. In addition, the limitation that states using “real-time”, “storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request”, states that the aggregated attributes can be used for real-time driver score calculation, and does not actively state that any of the calculations are being done in real-time. The term “real-time” is therefore recited for intended use and is not recited actively in the limitation.
Additional elements do not integrate the abstract idea into a practical application. The limitations of “receiving telematics data, the telematics data generated by a telematics device disposed within a vehicle”, “storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request”, and “after receiving a request from a provider computing device for the aggregated attributes, communicating the aggregated attributes to the provider computing device wherein the aggregated attributes are configured to be input into a provider model to provide processed driving insights that allow the provider computing device to calculate a driver score without requiring the provider computing device to process the telematics data over an extended data collection period”, are merely gathering, storing, and sending data. The receiving steps from the sensors and from the external source are recited at a high level of generality (i.e. as a general means of gathering vehicle and road condition data for use in the evaluating step), and amounts to mere data gathering, which is a form of insignificant extra-solution activity. The communicating information to the provider computing device which is then input into a generic model is also recited at a high level of generality, and amounts to mere post solution sending data, which is a form of insignificant extra-solution activity. The provider computing device and provider model are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of sorting information) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application. Therefore, the claims as amended are still directed to a 101 abstract idea. Accordingly, the 35 U.S.C. 101 rejection is maintained. See detailed rejection below.
Applicant's arguments filed December 22, 2025, have been fully considered but they are not persuasive. Regarding the 35 U.S.C. 103 rejection of claim 1, the applicant states that “The Office Action acknowledges that Fernandes does not disclose “storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request””, which the examiner respectfully disagrees, as the limitation has been newly added, therefore applicant’s arguments with respect to the limitation “storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request” have been considered but are moot. The examiner points to Fernandes (“The data storage device 214 may store, for example, (i) an operating system 216 for the computing device 200; (ii) one or more applications 218 (e.g., computer program code and/or a computer program product) adapted to direct the CPU 202 in accordance with the present invention, and particularly in accordance with the processes described in detail with regard to the CPU 202; and/or (iii) database(s) 220 adapted to store information that may be utilized to store information required by the program. The database(s) 220 may including all or a subset of data stored in insurance company database 116, described above with respect to FIG. 1, as well as additional data, such as formulas or manual adjustments, used in establishing the insurance risk for a vehicle.” [0037], “The storage device 1830 stores a program 1812 and/or scoring system 1814 for controlling the processor 1810. The processor 1810 performs instructions of the programs 1812, 1814, and thereby operates in accordance with any of the embodiments described herein. For example, the processor 1810 may receive telematics data associated with a vehicle. The processor 1810 may also analyze the telematics data and/or transmit discount information to a potential entity to be insured based at least in part on a computed risk score.” [0070]), and an example of data storage shown in (“In some embodiments (such as shown in FIG. 18), the storage device 1830 stores an underwriting database 1860 and/or a telematics database 1900. An example of a database that may be used in connection with the insurance platform 1800 will now be described in detail with respect to FIG. 19.” [0073]), which shows that the system stores the aggregated attributes, in which the collected data can be communicated for calculating driver scores. Therefore, it is clear that Fernandes teaches “storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request” because Fernandes teaches storing collected driving data aggregated for a database to be used for calculating a driver score.
In addition, the applicant argues that because Mathur teaches a self-contained system that performs all scoring internally, that Mathur does not teach the limitation “…without requiring the provider computing device to process the telematics data over an extended data collection period.” (page 3) and that neither reference teaches enabling an external provider to receive aggregated attributes and perform its own scoring calculations using its own model (page 4). However, the examiner respectfully disagrees, because while Mathur teaches the internal calculation where a probability of a user driving a vehicle and generating a risk score to develop at least one driver profile based on the computed probability, an analytics platform in the system quantifies the riskiness factor of each driver in a manner of driving the vehicle. This quantification is implemented in analyzing these risk scores which are attributed to each driver at a particular trip level and a driver level. The risk scores are further aggregated at the daily, weekly and monthly levels and can then be customized at any required level. The dynamic driver risk score module 218 is configured for computing the risk scores of an individual driver at the trip level, driver level and also aggregated risk scores at the day, week and month levels (see Mathur, [008], [020], [062]), the calculation of the driver score using aggregated attributes can be combined with the third part calculation of Fernandes, which teaches (“With a sufficient amount of data, the insurance company can calculate a level of risk score for the driver based on, for example, the driver's driving habits. The insurance company can use the score for setting or adjusting a discount value to be applied to an insurance premium. In some implementations, a score or discount is determined by a third party data processing service” [0022], “Using a data processing service 106 is in some implementations also preferable to having the data collection device 104 process data to output a risk score because it reduces the processing power needed by data collection device 104 and because using a third party data processing service 106 may also make it more difficult for drivers to tamper with the data.” [0024]), which teaches enabling an external provider, or a third party, to receive aggregated attributes and perform its own scoring calculations using its own model. Therefore, Fernandes and Mathur in combination teaches the amended limitation “and after receiving a request from a provider computing device for the aggregated attributes, communicating the aggregated attributes to the provider computing device wherein the aggregated attributes are configured to be input into a provider model to provide processed driving insights that allow the provider computing device to calculate a driver score without requiring the provider computing device to process the telematics data over an extended data collection period”. Accordingly, the 35 U.S.C. 103 rejection is maintained. Independent claims 9 and 16, which are similar to claim 1, are rejected for the same reasons as shown above. See detailed rejection below.
Dependent claims are rejected for the same reasons as above, due to dependency. See detailed rejection below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 1-20 are rejected under 35 U.S.C. 101, because the claimed invention is directed to an abstract idea without significantly more.
101 Analysis – Step 1
Independent claim 1 is directed toward a method, claim 9 is directed toward a system, and claim 16 is directed toward a non-transitory computer readable medium. Therefore, each of the independent claims 1, 9, and 16 along with the corresponding dependent claims 1, 9, and 16 are directed to a statutory category of invention under step 1.
101 Analysis – Step 2A, Prong 1
Under Step 2A, Prong 1, the claims are analyzed to determine whether one or more of the claims recites subject matter that falls within one of the following groups of abstract ideas: (1) mental processes, (2) certain methods of organizing human activity, and/or (3) mathematical concepts. In this case, the independent claims 1, 9, and 16 are directed to an abstract idea without significantly more. Specifically, the claims, under their broadest reasonable interpretation cover certain mental processes. The language of independent claim 1 is used for illustration:
A computer implemented method comprising: receiving telematics data, the telematics data generated by a telematics device disposed within a vehicle; (Pre solution insufficient activity);
determining driving attributes based on the telematics data; (A person could mentally observe and process data information);
combining and denormalizing the driving attributes by associating the driving attributes together based at least in part on matching corresponding timestamps to create denormalized attributes; (A person could mentally observe and process data information);
aggregating the denormalized attributes for a time period to create aggregated attributes; (A person could mentally observe and process data information);
and after receiving a request from a provider computing device for the aggregated attributes, communicating the aggregated attributes to the provider computing device wherein the aggregated attributes are configured to be input into a provider model to provide processed driving insights that allow the provider computing device to calculate a driver score without requiring the provider computing device to process the telematics data over an extended data collection period (Post solution insufficient activity);
As explained above, independent claim 1 recites at least one abstract idea. The other independent claims 9 and 16 which are of a similar scope to claim 1, likewise recite at least one abstract idea under Step 2A, Prong 1.
101 Analysis – Step 2A, Prong 2
Under Step 2A, Prong 2, the claims are analyzed to determine whether the claim, as a whole, integrates the abstract idea into a practical application. As noted in the 2019 PEG, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements such as merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application”; see at least MPEP 2106.04(d).
In this case, the mental processes judicial exception is/are not integrated into a practical application. For example, independent claims 1, 9, and 16 recite the additional elements of non-
transitory processor readable medium, one or more processing devices, and a data storage medium. These limitations amount to implementing the abstract idea on a computer, add insignificant extra solution activity, and/or generally link use of the judicial exception to a particular technological environment or field of use; see at least MPEP 2106.04(d). More specifically,
non-transitory processor readable medium… This limitation amounts to generally linking the use of the abstract idea to a particular technological environment or field of use
one or more processing devices… This limitation amounts to implementing the abstract idea on a computer
data storage medium… This limitation amounts to implementing the abstract idea on a computer
database… This limitation amounts to implementing the abstract idea on a computer
receiving a plurality of measure values… This limitation amounts to implementing the abstract idea on a computer
computing device… This limitation amounts to implementing the abstract idea on a computer
at least one processor… This limitation amounts to implementing the abstract idea on a computer
The receiving steps from the sensors and from the external source are recited at a high level of generality (i.e. as a general means of gathering vehicle and road condition data for use in the evaluating step), and amounts to mere data gathering, which is a form of insignificant extra-solution activity. The communicating information to the provider computing device which is then input into a generic model is also recited at a high level of generality, and amounts to mere post solution sending data, which is a form of insignificant extra-solution activity. The provider computing device and provider model are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of sorting information) such that it amounts no more than mere instructions to apply the exception using a generic computer component.
Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application. Furthermore, looking at the additional limitation(s) as an ordered combination or as a whole, the limitations add nothing significant that is not already present when looking at the elements taken individually. Because the additional elements, do not integrate the abstract idea into a practical application by imposing meaningful limits on practicing the abstract idea, independent claims 1, 9, and 16 are directed to an abstract idea.
101 Analysis – Step 2B
Regarding Step 2B of the 2019 PEG, representative independent claim 1 does not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a vehicle controller to perform the evaluating… amounts to nothing more than applying the exception using a generic computer component. Generally applying an exception using a generic computer component cannot provide an inventive concept. And as discussed above, the additional limitations of “non-transitory processor readable medium” “one or more processing devices” “data storage medium” “database” “receiving a plurality of measure values…,” the examiner submits that these limitations are insignificant extra-solution activities.
Further, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B to determine if they are more than what is well understood, routine, conventional activity in the field. The additional limitations of “one or more processing devices” “data storage medium” “database” “receiving a plurality of measure values…,” are well-understood, routine, and conventional activities because the background recites that the sensors are all conventional sensors mounted on the vehicle, and the specification does not provide any indication that the vehicle controller is anything other than a conventional computer within a vehicle. MPEP 2106.05(d)(II), and the cases cited therein, including Intellectual Ventures I, LLC v. Symantec Corp., 838 F.3d 1307, 1321 (Fed. Cir. 2016), TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610 (Fed. Cir. 2016), and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015), indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner. The Federal Circuit in Trading Techs. Int’l v. IBG LLC, 921 F.3d 1084, 1093 (Fed. Cir. 2019), and Intellectual Ventures I LLC v. Erie Indemnity Co., 850 F.3d 1315, 1331 (Fed. Cir. 2017), for example, indicated that the mere displaying of data is a well understood, routine, and conventional function. Hence, the claim is not patent eligible.
Dependent claims 2-8, 10-15, and 17-20 have been given the full two-part analysis, including analyzing the additional limitations, both individually and in combination. Dependent claims 2-8, 10-15, and 17-20 when analyzed both individually and in combination, are also patent ineligible under 35 U.S.C. 101 based on same analysis as above. The additional limitations recited in the dependent claims fail to establish that the dependent claims are not directed to an abstract idea. The additional limitations of the dependent claims, when considered individually and as an ordered combination, do not amount to significantly more than the abstract idea. Accordingly, claims 2-8, 10-15, and 17-20 are patent ineligible. Therefore, claims 1-20 are patent ineligible under 35 U.S.C. 101.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C.103 as being unpatentable over Fernandes et al (U.S. Pub. NO. 2015/0248731), as applied to independent claim 1 above, in view MATHUR et al. (U.S. Pub. NO. 2017/0364821).
With regard to claim 1, Fernandes discloses A computer implemented method comprising: (The reference discloses a computer method for receiving telematic data.) (Fernandes, abstract, [004])
Receiving telematics data, the telematics data generated by a telematics device disposed within a vehicle; (The reference discloses receiving telematics data from a devices and sensors within a vehicle.) (Fernandes, [005], [042])
Determining driving attributes based on the telematics data; (The reference discloses including determining driving behaviors from telematics data) (Fernandes, [004], [022], [023], [042])
Combining and denormalizing the driving attributes by associating the driving attributes together based at least in part on matching corresponding timestamps to create denormalized attributes; (The reference discloses transforming raw data into structured forms by collecting information like speed, acceleration, location, time of day information, and other behaviors and turning it into a risk score which is equivalent to combining and denormalizing the driving attributes denormalized attributes. Time of day information is equivalent to based at least in part on matching corresponding timestamps, the CPU sends the location data to the memory along with a time and date stamp.) (Fernandes, [024], [028], [043])
Aggregating the denormalized attributes for a time period to create aggregated attributes; (The reference discloses aggregation of driving data by calculating the aggregate risk rating based on the aggregate of the safety scores and calculated in substantially real time or be recalculated using new data when the driver's safety scores are more likely change which includes aggregating the denormalized attributes over a period of time.) (Fernandes, [024], [028], [036], [059])
storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request; (“storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request” have been considered but are moot. The examiner points to Fernandes (“The data storage device 214 may store, for example, (i) an operating system 216 for the computing device 200; (ii) one or more applications 218 (e.g., computer program code and/or a computer program product) adapted to direct the CPU 202 in accordance with the present invention, and particularly in accordance with the processes described in detail with regard to the CPU 202; and/or (iii) database(s) 220 adapted to store information that may be utilized to store information required by the program. The database(s) 220 may including all or a subset of data stored in insurance company database 116, described above with respect to FIG. 1, as well as additional data, such as formulas or manual adjustments, used in establishing the insurance risk for a vehicle.” [0037], “The storage device 1830 stores a program 1812 and/or scoring system 1814 for controlling the processor 1810. The processor 1810 performs instructions of the programs 1812, 1814, and thereby operates in accordance with any of the embodiments described herein. For example, the processor 1810 may receive telematics data associated with a vehicle. The processor 1810 may also analyze the telematics data and/or transmit discount information to a potential entity to be insured based at least in part on a computed risk score.” [0070]), and an example of data storage shown in (“In some embodiments (such as shown in FIG. 18), the storage device 1830 stores an underwriting database 1860 and/or a telematics database 1900. An example of a database that may be used in connection with the insurance platform 1800 will now be described in detail with respect to FIG. 19.” [0073]), which shows that the system stores the aggregated attributes, in which the collected data can be communicated for calculating driver scores.
And after receiving a request from a provider computing device for the aggregated attributes, communicating the aggregated attributes to the provider computing device, wherein the aggregated attributes are configured to be input into a provider model to provide processed driving insights, (The reference discloses sending aggregated safety scores to insurance companies or other entities who use the data for risk modeling to calculate based on the risk variables to generate a driving score which is the same as communicating the aggregated attributes to the aggregated attributes configured to be input into a provider model to calculate a driver score.) (Fernandes, [024], [028], [036], [053]), (“With a sufficient amount of data, the insurance company can calculate a level of risk score for the driver based on, for example, the driver's driving habits. The insurance company can use the score for setting or adjusting a discount value to be applied to an insurance premium. In some implementations, a score or discount is determined by a third party data processing service” [0022], “Using a data processing service 106 is in some implementations also preferable to having the data collection device 104 process data to output a risk score because it reduces the processing power needed by data collection device 104 and because using a third party data processing service 106 may also make it more difficult for drivers to tamper with the data.” [0024]), which teaches enabling an external provider, or a third party, to receive aggregated attributes and perform its own scoring calculations using its own model.)
However, Fernandes does not teach that allow the provider computing device to calculate a driver score without requiring the provider computing device to process the telematics data over an extended data collection period.
However, MATHUR teaches that allow the provider computing device to calculate a driver score without requiring the provider computing device to process the telematics data over an extended data collection period; (The reference teaches a probability of a user driving a vehicle and generating a risk score to develop at least one driver profile based on the computed probability, an analytics platform in the system quantifies the riskiness factor of each driver in a manner of driving the vehicle. This quantification is implemented in analyzing these risk scores which are attributed to each driver at a particular trip level and a driver level. The risk scores are further aggregated at the daily, weekly and monthly levels and can then be customized at any required level. The dynamic driver risk score module 218 is configured for computing the risk scores of an individual driver at the trip level, driver level and also aggregated risk scores at the day, week and month levels) (MATHUR, [008], [020], [062])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified A computer implemented method comprising: Receiving telematics data, the telematics data generated by a telematics device disposed within a vehicle; Determining driving attributes based on the telematics data; Combining and denormalizing the driving attributes by associating the driving attributes together based at least in part on matching corresponding timestamps to create denormalized attributes; storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request; Aggregating the denormalized attributes for a time period to create aggregated attributes; and after receiving a request from a provider computing device for the aggregated attributes, communicating the aggregated attributes to the provider computing device disclosed by Fernandes to include the wherein the aggregated attributes are configured to be input into a provider model to provide processed driving insights that allow the provider computing device to calculate a driver score without requiring the provider computing device to process the telematics data over an extended data collection period of MATHUR. One of ordinary skill in the art would have been motivated to make this modification of combining a system that streamlines driver evaluation by focusing on aggregated, pre-processed insights rather than exhaustive, raw data, allowing for quicker and potentially more efficient driver scoring with the prior limitations as suggested by MATHUR at [008], [020], [062] and Fernandes at [024], [028], [036], [053].
With regard to claim 2, Fernandes-MATHUR discloses all of the limitations of claim 1. Additionally, Fernandes discloses wherein the telematics device is a computing device of the vehicle. (The reference discloses collecting location data using gps which I receiving location data from sensors in the vehicle) (Fernandes, [022], [043])
With regard to claim 3, Fernandes-MATHUR discloses all of the limitations of claim 1. Additionally, Fernandes discloses wherein the telematics device is an on-board diagnostics device installed at the vehicle. (The reference discloses receiving acceleration data from accelerometers.) (Fernandes, [023], [042])
With regard to claim 4, Fernandes-MATHUR discloses all of the limitations of claim 1. Additionally, Fernandes discloses wherein the telematics device is a mobile computing device. (The reference discloses receiving speed data from sensors within a vehicle) (Fernandes, [022], [023], [042], [045])
With regard to claim 5, Fernandes-MATHUR discloses all of the limitations of claim 1. Additionally, Fernandes discloses wherein the telematics data generated by the telematics device include one or more of speed data, acceleration data, braking data, and location data. (The reference discloses determining safety events by analyzing speed, acceleration, breaking, and location data collected from telematics devices.) (Fernandes, [004], [006], [022], [054])
With regard to claim 6, Fernandes-MATHUR discloses all of the limitations of claim 1. Additionally, Fernandes discloses wherein the driving attributes include one or more of: braking attributes, time of day attributes, speeding attributes, and phone handling attributes. (The reference anticipates this by describing methods for identifying braking behavior using acceleration data.) (Fernandes, [022], [054], [056])
With regard to claim 7, Fernandes-MATHUR discloses all of the limitations of claim 1. Additionally, Fernandes discloses further comprising: receiving additional data; (The reference discloses receiving additional data such as trip data.) (Fernandes, [005], [031], [049])
And determining removed trips based on the additional data. (The reference discloses filtering out invalid or incomplete trips during aggregation using additional data.) (Fernandes, [022], [024], [056], [057])
With regard to claim 8, Fernandes-MATHUR discloses all of the limitations of claim 1. Additionally, Fernandes discloses further comprising sending the aggregated attributes to one or more databases. (The reference discloses storing aggregated telematics attributes in databases for further use.) (Fernandes, [025], [027], [037])
With regard to claim 9, Fernandes discloses A system comprising: (The reference discloses a system for receiving actual telematics data for a vehicle based on determination of an initial benefit from preliminary telematics data.) (Fernandes, Abstract, [008], [022])
A driving assessment platform including at least one processor configured to: (The reference discloses describes a processor and a driving assessment platform.) (Fernandes, [005], [019], [053])
Receive telematics data generated by a telematics device disposed within a vehicle; (The reference discloses collecting location data using gps which I receiving location data from sensors in the vehicle) (Fernandes, [022], [043])
Determine driving attributes based on the telematics data; (The reference discloses including determining driving behaviors from telematics data) (Fernandes, [004], [022], [023], [042])
Combining and denormalizing the driving attributes by associating the driving attributes together based at least in part on matching corresponding timestamps to create denormalized attributes; (The reference discloses transforming raw data into structured forms by collecting information like speed, acceleration, location, time of day information, and other behaviors and turning it into a risk score which is equivalent to combining and denormalizing the driving attributes denormalized attributes. Time of day information is equivalent to based at least in part on matching corresponding timestamps, the CPU sends the location data to the memory along with a time and date stamp.) (Fernandes, [024], [028], [043])
Aggregating the denormalized attributes for a time period to create aggregated attributes; (The reference discloses aggregation of driving data by calculating the aggregate risk rating based on the aggregate of the safety scores and calculated in substantially real time or be recalculated using new data when the driver's safety scores are more likely change which includes aggregating the denormalized attributes over a period of time.) (Fernandes, [024], [028], [036], [059])
storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request; (“The data storage device 214 may store, for example, (i) an operating system 216 for the computing device 200; (ii) one or more applications 218 (e.g., computer program code and/or a computer program product) adapted to direct the CPU 202 in accordance with the present invention, and particularly in accordance with the processes described in detail with regard to the CPU 202; and/or (iii) database(s) 220 adapted to store information that may be utilized to store information required by the program. The database(s) 220 may including all or a subset of data stored in insurance company database 116, described above with respect to FIG. 1, as well as additional data, such as formulas or manual adjustments, used in establishing the insurance risk for a vehicle.” [0037], “The storage device 1830 stores a program 1812 and/or scoring system 1814 for controlling the processor 1810. The processor 1810 performs instructions of the programs 1812, 1814, and thereby operates in accordance with any of the embodiments described herein. For example, the processor 1810 may receive telematics data associated with a vehicle. The processor 1810 may also analyze the telematics data and/or transmit discount information to a potential entity to be insured based at least in part on a computed risk score.” [0070]), and an example of data storage shown in (“In some embodiments (such as shown in FIG. 18), the storage device 1830 stores an underwriting database 1860 and/or a telematics database 1900. An example of a database that may be used in connection with the insurance platform 1800 will now be described in detail with respect to FIG. 19.” [0073]), which shows that the system stores the aggregated attributes, in which the collected data can be communicated for calculating driver scores.)
and after receiving a request from a provider computing device for the aggregated attributes, communicating the aggregated attributes to the provider computing device, wherein the aggregated attributes are configured to be input into a provider model to provide processed driving insights (The reference discloses sending aggregated safety scores to insurance companies or other entities who use the data for risk modeling to calculate based on the risk variables to generate a driving score which is the same as communicating the aggregated attributes to the aggregated attributes configured to be input into a provider model to calculate a driver score.) (Fernandes, [024], [028], [036], [053]) (“With a sufficient amount of data, the insurance company can calculate a level of risk score for the driver based on, for example, the driver's driving habits. The insurance company can use the score for setting or adjusting a discount value to be applied to an insurance premium. In some implementations, a score or discount is determined by a third party data processing service” [0022], “Using a data processing service 106 is in some implementations also preferable to having the data collection device 104 process data to output a risk score because it reduces the processing power needed by data collection device 104 and because using a third party data processing service 106 may also make it more difficult for drivers to tamper with the data.” [0024]), which teaches enabling an external provider, or a third party, to receive aggregated attributes and perform its own scoring calculations using its own model.)
However, Fernandes does not teach that allow the provider computing device to calculate a driver score without requiring the provider computing device to process the telematics data over an extended data collection period.
However, MATHUR teaches that allow the provider computing device to calculate a driver score without requiring the provider computing device to process the telematics data over an extended data collection period; (The reference teaches a probability of a user driving a vehicle and generating a risk score to develop at least one driver profile based on the computed probability, an analytics platform in the system quantifies the riskiness factor of each driver in a manner of driving the vehicle. This quantification is implemented in analyzing these risk scores which are attributed to each driver at a particular trip level and a driver level. The risk scores are further aggregated at the daily, weekly and monthly levels and can then be customized at any required level. The dynamic driver risk score module 218 is configured for computing the risk scores of an individual driver at the trip level, driver level and also aggregated risk scores at the day, week and month levels) (MATHUR, [008], [020], [062])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified A system comprising: A driving assessment platform including at least one processor configured to: Receive telematics data generated by a telematics device disposed within a vehicle; Determine driving attributes based on the telematics data; Combining and denormalizing the driving attributes by associating the driving attributes together based at least in part on matching corresponding timestamps to create denormalized attributes; Aggregating the denormalized attributes for a time period to create aggregated attributes; And sending the aggregated attributes to one or more databases; storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request; and after receiving a request from a provider computing device for the aggregated attributes, communicating the aggregated attributes to the provider computing device, disclosed by Fernandes to include the wherein the aggregated attributes are configured to be input into a provider model to provide processed driving insights that allow the provider computing device to calculate a driver score without requiring the provider computing device to process the telematics data over an extended data collection period of MATHUR. One of ordinary skill in the art would have been motivated to make this modification a system that streamlines driver evaluation by focusing on aggregated, pre-processed insights rather than exhaustive, raw data, allowing for quicker and potentially more efficient driver scoring with the prior limitations as suggested by MATHUR at [008], [020], [062] and Fernandes at [024], [028], [036], [053].
With regard to claim 10, Fernandes-MATHUR discloses all of the limitations of claim 9. Additionally, Fernandes discloses wherein the telematics device is a computing device of the vehicle. (The reference discloses using a OBD and smartphone devices as a telematics system that is installed in a vehicle.) (Fernandes, [023], [028], [029], [042])
With regard to claim 11, Fernandes-MATHUR discloses all of the limitations of claim 9. Additionally, Fernandes discloses wherein the telematics device is an on-board diagnostics device installed at the vehicle. (The reference discloses using a On Board Diagnostics or OBD device as a telematics system that is installed in a vehicle.) (Fernandes, [023], [042])
With regard to claim 12, Fernandes-MATHUR discloses all of the limitations of claim 9. Additionally, Fernandes discloses wherein the telematics device is a mobile computing device. (The reference discloses a mobile computing device as telematic systems such as smartphones installed or used within the vehicles.) (Fernandes, [023], [028], [029])
With regard to claim 13, Fernandes-MATHUR discloses all of the limitations of claim 9. Additionally, Fernandes discloses wherein the telematics data include one or more of: speed data, acceleration data, braking data, and location data. (The reference discloses determining safety events by analyzing speed, acceleration, breaking, and location data collected from telematics devices.) (Fernandes, [004], [006], [022], [054])
With regard to claim 14, Fernandes-MATHUR discloses all of the limitations of claim 9. Additionally, Fernandes discloses wherein the driving attributes include one or more of: braking attributes, time of day attributes, speeding attributes, and phone handling attributes. (The reference anticipates this by describing methods for identifying braking behavior using acceleration data.) (Fernandes, [022], [054], [056])
With regard to claim 15, Fernandes-MATHUR discloses all of the limitations of claim 9. Additionally, Fernandes discloses wherein the driving assessment platform including the at least one processor is further configured to: (The reference discloses describes a processor and a driving assessment platform.) (Fernandes, [005], [019], [053])
Receive additional data from the one or more databases; (The reference discloses receiving additional data such as trip data.) (Fernandes, [005], [031], [049])
And determine removed trips based on the additional data. (The reference discloses filtering out invalid or incomplete trips during aggregation using additional data.) (Fernandes, [022], [024], [056], [057])
With regard to claim 16, Fernandes discloses One or more tangible non-transitory computer-readable storage media storing computer- executable instructions for performing a computer process on a computing system, the computer process comprising: (The reference discloses a non-transitory medium that provides or participates in providing instructions to the processor of the computing device) (Fernandes,[007], [040])
Receiving telematics data, the telematics data generated by a telematics device disposed within a vehicle; (The reference discloses receiving telematics data from a devices and sensors within a vehicle.) (Fernandes, [005], [042])
Determining driving attributes based on the telematics data; (The reference discloses including determining driving behaviors from telematics data) (Fernandes, [004], [022], [023], [042])
Combining and denormalizing the driving attributes by associating the driving attributes together based at least in part on matching corresponding timestamps to create denormalized attributes; (The reference discloses transforming raw data into structured forms by collecting information like speed, acceleration, location, time of day information, and other behaviors and turning it into a risk score which is equivalent to combining and denormalizing the driving attributes denormalized attributes. Time of day information is equivalent to based at least in part on matching corresponding timestamps, the CPU sends the location data to the memory along with a time and date stamp.) (Fernandes, [024], [028], [043])
Aggregating the denormalized attributes for a time period to create aggregated attributes; sending the aggregated attributes to the one or more databases; (The reference discloses aggregation of driving data by calculating the aggregate risk rating based on the aggregate of the safety scores and calculated in substantially real time or be recalculated using new data when the driver's safety scores are more likely change which includes aggregating the denormalized attributes over a period of time.) (Fernandes, [024], [028], [036], [059])
storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request; (“storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request” have been considered but are moot. The examiner points to Fernandes (“The data storage device 214 may store, for example, (i) an operating system 216 for the computing device 200; (ii) one or more applications 218 (e.g., computer program code and/or a computer program product) adapted to direct the CPU 202 in accordance with the present invention, and particularly in accordance with the processes described in detail with regard to the CPU 202; and/or (iii) database(s) 220 adapted to store information that may be utilized to store information required by the program. The database(s) 220 may including all or a subset of data stored in insurance company database 116, described above with respect to FIG. 1, as well as additional data, such as formulas or manual adjustments, used in establishing the insurance risk for a vehicle.” [0037], “The storage device 1830 stores a program 1812 and/or scoring system 1814 for controlling the processor 1810. The processor 1810 performs instructions of the programs 1812, 1814, and thereby operates in accordance with any of the embodiments described herein. For example, the processor 1810 may receive telematics data associated with a vehicle. The processor 1810 may also analyze the telematics data and/or transmit discount information to a potential entity to be insured based at least in part on a computed risk score.” [0070]), and an example of data storage shown in (“In some embodiments (such as shown in FIG. 18), the storage device 1830 stores an underwriting database 1860 and/or a telematics database 1900. An example of a database that may be used in connection with the insurance platform 1800 will now be described in detail with respect to FIG. 19.” [0073]), which shows that the system stores the aggregated attributes, in which the collected data can be communicated for calculating driver scores.)
and after receiving a request from a provider computing device for the aggregated attributes, communicating the aggregated attributes to the provider computing device, wherein the aggregated attributes are configured to be input into a provider model to provide processed driving insights (The reference discloses sending aggregated safety scores to insurance companies or other entities who use the data for risk modeling to calculate based on the risk variables to generate a driving score which is the same as communicating the aggregated attributes to the aggregated attributes configured to be input into a provider model to calculate a driver score.) (Fernandes, [024], [028], [036], [053]) (“With a sufficient amount of data, the insurance company can calculate a level of risk score for the driver based on, for example, the driver's driving habits. The insurance company can use the score for setting or adjusting a discount value to be applied to an insurance premium. In some implementations, a score or discount is determined by a third party data processing service” [0022], “Using a data processing service 106 is in some implementations also preferable to having the data collection device 104 process data to output a risk score because it reduces the processing power needed by data collection device 104 and because using a third party data processing service 106 may also make it more difficult for drivers to tamper with the data.” [0024]), which teaches enabling an external provider, or a third party, to receive aggregated attributes and perform its own scoring calculations using its own model.)
However, Fernandes does not teach that allow the provider computing device to calculate a driver score without requiring the provider computing device to process the telematics data over an extended data collection period.
However, MATHUR teaches that allow the provider computing device to calculate a driver score without requiring the provider computing device to process the telematics data over an extended data collection period; (The reference teaches a probability of a user driving a vehicle and generating a risk score to develop at least one driver profile based on the computed probability, an analytics platform in the system quantifies the riskiness factor of each driver in a manner of driving the vehicle. This quantification is implemented in analyzing these risk scores which are attributed to each driver at a particular trip level and a driver level. The risk scores are further aggregated at the daily, weekly and monthly levels and can then be customized at any required level. The dynamic driver risk score module 218 is configured for computing the risk scores of an individual driver at the trip level, driver level and also aggregated risk scores at the day, week and month levels) (MATHUR, [008], [020], [062])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified One or more tangible non-transitory computer-readable storage media storing computer- executable instructions for performing a computer process on a computing system, the computer process comprising: Receiving telematics data, the telematics data generated by a telematics device disposed within a vehicle; Determining driving attributes based on the telematics data; Combining and denormalizing the driving attributes by associating the driving attributes together based at least in part on matching corresponding timestamps to create denormalized attributes; Aggregating the denormalized attributes for a time period to create aggregated attributes; sending the aggregated attributes to the one or more databases; storing the aggregated attributes for immediate communication to facilitate substantially real-time driver score calculation upon request; and after receiving a request from a provider computing device for the aggregated attributes, communicating the aggregated attributes to the provider computing device, disclosed by Fernandes to include the wherein the aggregated attributes are configured to be input into a provider model to provide processed driving insights that allow the provider computing device to calculate a driver score without requiring the provider computing device to process the telematics data over an extended data collection period of MATHUR. One of ordinary skill in the art would have been motivated to make this modification a system that streamlines driver evaluation by focusing on aggregated, pre-processed insights rather than exhaustive, raw data, allowing for quicker and potentially more efficient driver scoring with the prior limitations as suggested by MATHUR at [008], [020], [062] and Fernandes at [024], [028], [036], [053].
With regard to claim 17, Fernandes-MATHUR discloses all of the limitations of claim 16. Additionally, Fernandes discloses speed data, acceleration data, braking data, and location data. (The reference discloses determining safety events by analyzing speed, acceleration, breaking, and location data collected from telematics devices.) (Fernandes, [004], [006], [022], [054])
With regard to claim 18, Fernandes-MATHUR discloses all of the limitations of claim 16. Additionally, Fernandes discloses braking attributes, time of day attributes, speeding attributes, and phone handling attributes. (The reference anticipates this by describing methods for identifying braking behavior using acceleration, speed and phone data.) (Fernandes, [022], [054], [056])
With regard to claim 19, Fernandes-MATHUR discloses all of the limitations of claim 16. Additionally, Fernandes discloses receiving additional data from the one or more databases; (The reference discloses receiving additional data such as trip data.) (Fernandes, [005], [031], [049])
And determining removed trips based on the additional data. (The reference discloses filtering out invalid or incomplete trips during aggregation using additional data.) (Fernandes, [022], [024], [056], [057])
With regard to claim 20, Fernandes-MATHUR discloses all of the limitations of claim 16. Additionally, Fernandes discloses a computing device of the vehicle or a mobile computing device. (The reference discloses a mobile computing device as telematic systems such as smartphones.) (Fernandes, [023], [028], [029])
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Christine N Huynh whose telephone number is (571)272-9980. The examiner can normally be reached Monday - Friday 8 am - 4 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aniss Chad can be reached at (571)270-3832. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHRISTINE NGUYEN HUYNH/Examiner, Art Unit 3662
/ANISS CHAD/Supervisory Patent Examiner, Art Unit 3662