DETAILED ACTION
Status of the Application
Claims 1-20 are pending and currently under consideration for patentability under 37 CFR 1.104.
Priority
The instant application has a filing date of June 10, 2025, and claims priority as a continuation (CON) of US non-provisional Application # 18/065,847 (filing date of December 14, 2022), which is a national phase under 35 U.S.C. 371 of PCT International Application No. US2021/040317, filed on July 2, 2021; and claims for the benefit of prior-filed provisional application # 63/049,052, which was filed on July 7, 2020. Applicant’s claim for the benefit of the prior-filed provisional application is acknowledged.
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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on September 26, 2025 and April 14, 2026 have been considered by the examiner.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
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.
v Claim(s) 1-20 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1:
Claim(s) 1-9 is/are drawn to methods (i.e., a process), claim(s) 10-18 is/are drawn to systems (i.e., a machine/manufacture), and claim(s) 19 and 20 is/are drawn to non-transitory computer readable storage medium (i.e., a machine/manufacture). As such, claims 1-20 is/are drawn to one of the statutory categories of invention (Step 1: YES).
Step 2A - Prong One:
In prong one of step 2A, the claim(s) is/are analyzed to evaluate whether it/they recite(s) a judicial exception.
Claim 1 (representative of independent claim(s) 10 and 19) recites/describes the following steps;
collecting, during a first time period before a user management event, a first set of operator data associated with vehicle operators, the first set of operator data comprising (a) a first set of personal data associated with the vehicle operators, (b) a first set of telematics data comprising a first set of sensor data associated with the vehicle operators…,and (c) a first set of user management data associated with the vehicle operators,…the first set of telematics data in a standardized format across the devices
applying the user management event to the vehicle operators, the vehicle operators being managed by a marketplace participant,
collecting, during a second time period after a user management event, a second set of operator data associated with the vehicle operators, the second set of operator data comprising (a) a second set of personal data associated with the vehicle operators, (b) a second set of telematics data comprising a second set of sensor data associated with the vehicle operators…, and (c) a second set of user management data associated with the vehicle operators,…the second set of telematics data in the standardized format
determining a first set of telematics inferences in the standardized format based at least on the first set of sensor data by using one or more universal predictive models, wherein the first set of telematics inferences are indicative of at least driving characteristics exhibited by the vehicle operators during the first time period,
determining and updating a second set of telematics inferences in the standardized format based at least on the second set of sensor data by using the one or more universal predictive models, wherein the second set of telematics inferences are indicative of at least driving characteristics exhibited by the vehicle operators during the second time period,
determining and updating an event evaluation based at least on one or more differences between the first set of telematics inferences and the second set of telematics inferences
transmitting the event evaluation to the marketplace participant
These steps, under its broadest reasonable interpretation, describe or set-forth collecting/gathering a variety of data associated with vehicle operators and vehicle management over different time periods (e.g., personal data, telematics data, user management data) before and after a management event, deriving one or more telematic inferences (e.g., metrics/scores, such as profitability scores) for each time period based on this data, determining and updating an event evaluation based at least in part upon one or more differences between the first set of telematics inferences and the second set of telematics inferences, and transmitting the event evaluation to the marketplace participant (e.g., insurer), which amounts to a commercial or legal interactions (e.g., fundamental economic practices such as insurance or mitigating risk and/or an advertising, marketing or sales activity or behavior; business relations). These limitations therefore fall within the “certain methods of organizing human activity” subject matter grouping of abstract ideas.
As such, the Examiner concludes that claim 1 recites an abstract idea (Step 2A – Prong One: YES).
Independent claim(s) 10 and 19 recite/describe nearly identical steps (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this/these claim(s) is/are therefore determined to recite an abstract idea under the same analysis.
Each of the depending claims likewise recite/describe these steps (by incorporation - and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this/these claim(s) is/are therefore determined to recite an abstract idea under the same analysis. Any element(s) recited in a dependent claim that are not specifically identified/addressed by the Examiner under step 2A (prong two) or step 2B of this analysis shall be understood to be an additional part of the abstract idea recited by that particular claim.
Step 2A - Prong Two:
In prong two of step 2A, an evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the exception into a practical application of that exception. An “addition element” is an element that is recited in the claim in addition to (beyond) the judicial exception (i.e., an element/limitation that sets forth an abstract idea is not an additional element). The phrase “integration into a practical application” is defined as requiring an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception.
The claim(s) recite the additional elements/limitations of
“computer-implemented” (claim 1)
“a system comprising one or more processors and one or more non-transitory computer- readable media comprising computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations comprising” (claim 10)
“one or more non-transitory computer-readable media storing computing instructions that, when executed by one or more processors, cause the one or more processors to perform operations” (claim 19)
“a first set of telematics data…via a software development kit (SDK) commonly installed on devices comprising multiple of: (1) mobile devices of the vehicle operators, (2) third-party applications installed on the mobile devices, or (3) on-board computers of vehicles of the vehicle operators, …wherein the SDK produces…a second set of telematics data…via the SDK…wherein the SDK produces…” (claims 1, 10, and 19)
The requirement to execute the claimed steps/functions via “computer-implemented” means (claim 1) or via “a system comprising one or more processors and one or more non-transitory computer- readable media comprising computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations comprising” (claim 10) or via “one or more non-transitory computer-readable media storing computing instructions that, when executed by one or more processors, cause the one or more processors to perform operations” (claim 19) and/or with “a first set of telematics data…via a software development kit (SDK) commonly installed on devices comprising multiple of: (1) mobile devices of the vehicle operators, (2) third-party applications installed on the mobile devices, or (3) on-board computers of vehicles of the vehicle operators, …wherein the SDK produces…a second set of telematics data…via the SDK…wherein the SDK produces…” (claims 1, 10, and 19) is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. Applicant’s own specification suggests that these elements may be general-purpose computers or computing components (e.g., paras [0060]-[0062] and [0186]-[0188] and [0202]-[0205] of Applicant’s published disclosure). Furthermore, the recited SDK are conventional computers or other machinery that are invoked merely as a tool to perform an existing process (i.e., add data collection functions to existing computers/applications and enable the existing computers/applications to interface/communicate with a remote platform/system/server) and that are being used in their ordinary capacity. In other words, the claims invoke the SDK merely as tools to execute the abstract idea. This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(f)).
The recited additional element(s) of “a first set of telematics data…via a software development kit (SDK) commonly installed on devices comprising multiple of: (1) mobile devices of the vehicle operators, (2) third-party applications installed on the mobile devices, or (3) on-board computers of vehicles of the vehicle operators, …wherein the SDK produces…a second set of telematics data…via the SDK…wherein the SDK produces…” (claims 1, 10, and 19) also serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. Specifically, it/they serve(s) to limit the application of the abstract idea to computing environments, such as distributed computing environments and/or the internet, where information is represented digitally, exchanged between computers (e.g., mobile devices, vehicle computers). It also serves merely to limit the data collection to be from certain types of computers. This reasoning was demonstrated in Intellectual Ventures I LLC v. Capital One Bank (Fed. Cir. 2015), where the court determined "an abstract idea does not become nonabstract by limiting the invention to a particular field of use or technological environment, such as the Internet [or] a computer"). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(g)).
The recited element(s) of “collecting, during a first time period before a user management event, a first set of operator data associated with vehicle operators, the first set of operator data comprising (a) a first set of personal data associated with the vehicle operators, (b) a first set of telematics data comprising a first set of sensor data associated with the vehicle operators via a software development kit (SDK) commonly installed on devices comprising multiple of: (1) mobile devices of the vehicle operators, (2) third-party applications installed on the mobile devices, or (3) on-board computers of vehicles of the vehicle operators, and (c) a first set of user management data associated with the vehicle operators, wherein the SDK produces the first set of telematics data in a standardized format across the devices” (claims 1, 10, and 19) and/or “collecting, during a second time period after a user management event, a second set of operator data associated with the vehicle operators, the second set of operator data comprising (a) a second set of personal data associated with the vehicle operators, (b) a second set of telematics data comprising a second set of sensor data associated with the vehicle operators via the SDK, and (c) a second set of user management data associated with the vehicle operators, wherein the SDK produces the second set of telematics data in the standardized format” (claims 1, 10, and 19) and/or “transmitting the event evaluation to the marketplace participant “ (claims 1, 10, and 19), even if they were considered to be “additional elements” in the claims, would simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea; mere post-solution activity in conjunction with an abstract idea). The term “extra-solution activity” is understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim. The recited additional element(s) do are deemed “extra-solution” because the collection of the data and the transmission of the result would be required in any implementation of the abstract idea, and because the courts have long held this type of data gathering and result/data transmission to be insignificant pre and post-solution activity. This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(h)).
Furthermore, although the claims recite a specific sequence of computer-implemented functions, and although the specification suggests certain functions may be advantageous for various reasons (e.g., business reasons), the Examiner has determined that the ordered combination of claim elements (i.e., the claims as a whole) are not directed to an improvement to computer functionality/capabilities, an improvement to a computer-related technology or technological environment, and do not amount to a technology-based solution to a technology-based problem. For example, Applicant’s published specification suggests that it is advantageous to implement the claimed business process because doing so can enable one or more marketplace participants to gain valuable insights regarding vehicle operators, and or can help maintain data privacy and/or maintain neutrality (see, for example, Applicant’s published disclosure at paragraphs [0076], [0079], [0087], [0089] ). These are non-technical business advantages/improvements. At most, the ordered combination of claim elements is directed to a non-technical improvement to an abstract idea itself (e.g., an improved process for deriving one or more telematic inferences (e.g., metrics/scores, such as profitability scores) for each time period, and for determining and updating an event evaluation based at least in part upon one or more differences between the first set of telematics inferences and the second set of telematics inferences (e.g., insurer). Furthermore, Examiner finds no unconventional arrangement of additional elements to provide any additional advantages alluded to in the specification.
Dependent claims 2-9, 11-18, and 20 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims 2-9, 11-18, and 20 is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e. they are part of the abstract idea recited in each respective claim). For example, claim 2 recites “wherein, the determining the first set of telematics inferences comprises determining a first predicted profitability based at least in part on the first set of personal data and the first set of sensor data, and determining and updating the second set of telematics inferences includes determining and updating a second predicted profitability based at least in part on the second set of personal data and the second set of sensor data”. This is an abstract limitation which further sets forth the abstract idea encompassed by claim 2. This limitation is not an “additional element”, and therefore it is not subject to further analysis under Step 2A- Prong Two or Step 2B. The same logic applies to each of the other dependent claims, whose limitations are not being repeated here for the sake of brevity and clarity. With respect to the other dependent claims not specifically listed here - each of the limitations/elements recited in these dependent claims other than those identified as being “additional” elements above (at the beginning of the Prong One analysis), are further part of the abstract idea encompassed by each respective dependent claim (i.e. it should be understood that these limitations are part of the abstract idea recited in each respective claim).
The Examiner has therefore determined that the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application. Accordingly, the claim(s) is/are directed to an abstract idea (Step 2A – Prong two: NO).
Step 2B:
In step 2B, the claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception. This analysis is also termed a search for an "inventive concept." An "inventive concept" is furnished by an element or combination of elements that is recited in the claim in addition to (beyond) the judicial exception, and is sufficient to ensure that the claim as a whole amounts to significantly more than the judicial exception itself. Alice Corp., 134 S. Ct. at 2355, 110 USPQ2d at 1981 (citing Mayo, 566 U.S. at 72-73, 101 USPQ2d at 1966)
As discussed above in “Step 2A – Prong 2”, the requirement to execute the claimed steps/functions via “computer-implemented” means (claim 1) or via “a system comprising one or more processors and one or more non-transitory computer- readable media comprising computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations comprising” (claim 10) or via “one or more non-transitory computer-readable media storing computing instructions that, when executed by one or more processors, cause the one or more processors to perform operations” (claim 19) and/or with “a first set of telematics data…via a software development kit (SDK) commonly installed on devices comprising multiple of: (1) mobile devices of the vehicle operators, (2) third-party applications installed on the mobile devices, or (3) on-board computers of vehicles of the vehicle operators, …wherein the SDK produces…a second set of telematics data…via the SDK…wherein the SDK produces…” (claims 1, 10, and 19) is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. These limitations therefore do not qualify as “significantly more” (see MPEP 2106.05(f)).
As discussed above in “Step 2A – Prong 2”, the recited additional element(s) of “a first set of telematics data…via a software development kit (SDK) commonly installed on devices comprising multiple of: (1) mobile devices of the vehicle operators, (2) third-party applications installed on the mobile devices, or (3) on-board computers of vehicles of the vehicle operators, …wherein the SDK produces…a second set of telematics data…via the SDK…wherein the SDK produces…” (claims 1, 10, and 19) serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. These limitations therefore do not qualify as “significantly more” (see MPEP 2106.05(g)).
As discussed above in “Step 2A – Prong 2”, the recited element(s) of “collecting, during a first time period before a user management event, a first set of operator data associated with vehicle operators, the first set of operator data comprising (a) a first set of personal data associated with the vehicle operators, (b) a first set of telematics data comprising a first set of sensor data associated with the vehicle operators via a software development kit (SDK) commonly installed on devices comprising multiple of: (1) mobile devices of the vehicle operators, (2) third-party applications installed on the mobile devices, or (3) on-board computers of vehicles of the vehicle operators, and (c) a first set of user management data associated with the vehicle operators, wherein the SDK produces the first set of telematics data in a standardized format across the devices” (claims 1, 10, and 19) and/or “collecting, during a second time period after a user management event, a second set of operator data associated with the vehicle operators, the second set of operator data comprising (a) a second set of personal data associated with the vehicle operators, (b) a second set of telematics data comprising a second set of sensor data associated with the vehicle operators via the SDK, and (c) a second set of user management data associated with the vehicle operators, wherein the SDK produces the second set of telematics data in the standardized format” (claims 1, 10, and 19) and/or “transmitting the event evaluation to the marketplace participant “ (claims 1, 10, and 19), even if they were considered to be “additional elements” in the claims, would simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea; mere post-solution activity in conjunction with an abstract idea). These additional element(s), taken individually or in combination, would additionally amount to well-understood, routine and conventional activities previously known to the industry, specified at a high level of generality, appended to the judicial exception. These additional elements, taken individually or in combination, are well-understood, routine and conventional to those in the field of vehicle telematics data collection and analysis. These limitations therefore do not qualify as “significantly more”. (see MPEP 2106.05(d)).This conclusion is based on a factual determination. The determination that receiving data/messages over a network is well-understood, routine, and conventional is supported by Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362; TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014), and MPEP 2106.05(d)(II), which note the well-understood, routine, conventional nature of receiving data/messages over a network. Furthermore, Examiner takes Official Notice that these steps were well-understood, routine, and conventional at the effective filing date of the claimed invention in the field of vehicle telematics data collection and analysis. Furthermore, the lack of technical detail/description in Applicant’s own specification provides implicit evidence that these steps were well-understood, routine, and conventional.
Viewing the additional limitations in combination also shows that they fail to ensure the claims amount to significantly more than the abstract idea. When considered as an ordered combination, the additional components of the claims add nothing that is not already present when considered separately, and thus simply append the abstract idea with words equivalent to “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer, and append the abstract idea with insignificant extra solution activity associated with the implementation of the judicial exception, (e.g., mere data gathering, post-solution activity), and appended with well-understood, routine and conventional activities previously known to the industry.
Dependent claims 2-9, 11-18, and 20 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims 2-9, 11-18, and 20 is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e. they are part of the abstract idea identified by the Examiner to which each respective claim is directed).
The Examiner has therefore determined that no additional element, or combination of additional claims elements is/are sufficient to ensure the claim(s) amount to significantly more than the abstract idea identified above (Step 2B: NO).
Claim Rejections - 35 USC § 103
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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
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 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.
v Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Khoury (U.S. PG Pub No. 2017/0255966 September 7, 2017 - hereinafter "Khoury”) in view of Sadiq et al. (U.S. PG Pub No. 2014/0195272 July 10, 2014 - hereinafter "Sadiq”) in view of “DriveWell SDK” (published online by Cambridge Mobile Telematics on March 20, 2020 at https://www.cmtelematics.com/blog/drivewell-sdk-get-the-most-accurate-driving-insights/ and related webpages published on March 5, 2020 at https://www.cmtelematics.com/blog/drivewell-score-predict-lower-risk and February 27, 2020 at https://www.cmtelematics.com/blog/drivewell-assess-risk-and-encourage-safer-driving/)
With respect to claims 1, 10, and 19, Khoury teaches a computer-implemented method, a system comprising one or more processors ([0043]-[0045] “one or more processors”) and one or more non-transitory computer- readable media comprising computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations ([0043]-[0045] “memory”), and one or more non-transitory computer-readable media storing computing instructions that, when executed by one or more processors, cause the one or more processors to perform operations ([0043]-[0045] “memory”), comprising:
collecting, during a first time period before a user management event, a first set of operator data associated with vehicle operators ([0011] “for each driver or, in a case of a fleet…aggregating the encoded driving vehicles of all vehicles of the fleet…per time period” – therefore collects the data for plurality/group of drivers being managed by a marketplace participant over different time periods (e.g., first, second, etc.), [0028] “predict…profitability of drivers or fleets…classify the potential profitability of certain individuals or groups of individuals or fleets of vehicles…” – data collected for operators associated with a group of operators managed by a vehicle marketplace participant (e.g., fleet owner or fleet/segment/group insurance provider, [0045] “providing…over time, profitability data such as…claims data for the drivers that have selected their products”)
the first set of operator data comprising (a) a first set of personal data associated with the vehicle operators ([0010] “synchronized with the driver’s virtual activity on internet browsers to represent, in the profile of the driver, web sites visited…and physical establishments visited…”, [0011] “plurality of features of the driver including…age, gender, zip code, credit score, type of care driven, and historical infractions…”, [0045] “forms or questionnaires at various points in time and as needed”, [0062] “questionnaire…sent from time-to-time…contribute to the accuracy of the profitability predictions”, [0067])
(b) a first set of telematics data comprising a first set of sensor data associated with the vehicle operators via software commonly installed on devices comprising multiple of: (1) mobile devices of the vehicle operators, (2) third-party applications installed on the mobile devices, or (3) on-board computers of vehicles of the vehicle operators, wherein the software produces the first set of telematics data in a standardized format across the devices ([0007] “collecting driving information using a device associated with a driver and a vehicle…routes…locations…times of day…speeds…encoding….transmitting…to a server…storing…an identifier associated with the driver…classifying into one or more groups”, [0029] standardized, [0036] “example mobile device associated with a specific driver that has stored in its device storage 109 code that embodies the functionality of a method for collecting driving information. FIG. 1 also illustrates a high-level architecture of an analytics module/agent 104 assisting data flow between a device storage 109, the device's local processor CPU 102, and an analytics centralized server 150, and device systems including device radios 105, device GPS 107, and device local sensors 103. The analytics agent 104 receives/collects data from the device systems that may be stored on the device storage 109 and a local application device database 101 or may be transmitted back to the analytics server 150…data collection activity can runs as a background thread on the device and does not block the normal functioning of the device. The software code residing in device storage 109 can cause the device processor 102 to periodically make measurements using various local sensors 103 using appropriate APIs…measurements sequence requested by the instructions in the software…may use all location methods available on the mobile device including…location information provided by the device itself (based on services provided by the device itself such as GSP, Assisted GPS method, Standalone GPS method, Cell ID method, enhanced cell ID method using known sectorized cells IDs…as well as accelerometer sensors of the device” – telematics data comprising sets of sensor data via software code commonly installed on each drivers mobile device (i.e., multiple mobile devices of the vehicle operators) and therefore the data is produced/received in a standardized format, [0045] “the server 307a may be accessible by any of a plurality of drivers' mobile devices 310a (e.g., a mobile phone or tablet device)… An application installed on a mobile device 310a may be required to communicate with the server 307a and transmit data such as encoded route information…”, [0043] “Communications between the network nodes are typically effected by exchanging discrete packets of data. Each packet typically comprises (1) header information associated with a particular protocol, and (2) payload information that follows the header information and contains information that may be processed independently of that particular protocol. In some protocols, the packet includes (3) trailer information following the payload and indicating the end of the payload information”, [0052] “captured in encoded form…speed and route…acceleration, deceleration, time…in a SQL lite structured database…uploads the encoded data to the centralized system server”, [0091]-[0097] “this kind of analysis has been attempted using short term vehicle tracking using devices such as the Progressive' s Snapshot device that plugs into a car's OBD port…Another major issue with these types of devices is that the information captured is proprietary to a specific insurance carrier and, therefore, cannot be used if the driver wishes to switch insurance companies….The disclosed systems can place the tracking data in the hands of third-party intermediaries, rather than in the hands of the providers of products and services. An example system can include an industry wide exchange module that gives product and service providers access to a profit segmented base of drivers or fleets…” – acknowledges issues with non-centralized non-standardized data is a problem being addressed)
and (c) a first set of user management data associated with the vehicle operators ([0011] “…historical claims…associated claims…actual loss and claims data being provided…to correspond more closely to an actual insurance risk as calculated from actual loss and claims data provided over time”, [0045] “data provided by products and service providers such as actual profitability of drivers…claims data…providing…over time, profitability data such as…claims data for the drivers that have selected their products”, [0136]-[0137]))
applying the user management event to the vehicle operators, the vehicle operators being managed by a marketplace participant ([0049] “system can send targeted messages to the mobile device of the driver encouraging changes in driving behavior that may result in a re-classification of the risk and predicted profitability…”, [0089] “the classification…determines the premiums paid” – therefore an insurer may adjust a user’s premium if they are classified into a lower risk or higher profitability group which is a “user management event” (see also [0011]), [0011] “for each driver or, in a case of a fleet…aggregating the encoded driving vehicles of all vehicles of the fleet…per time period” – therefore collects the data for plurality/group of drivers being managed by a marketplace participant over different time periods (e.g., first, second, etc.), [0028] “predict…profitability of drivers or fleets…classify the potential profitability of certain individuals or groups of individuals or fleets of vehicles…” – data collected for operators associated with a group of operators managed by a vehicle marketplace participant (e.g., fleet owner or fleet/segment/group insurance provider, [0045] “providing…over time, profitability data such as…claims data for the drivers that have selected their products”)
collecting, during a second time period after a user management event, a second set of operator data associated with the vehicle operators [0011] “for each driver or, in a case of a fleet…aggregating the encoded driving vehicles of all vehicles of the fleet…per time period” – therefore collects the data for plurality/group of drivers being managed by a marketplace participant over different time periods (e.g., first, second, etc.) which may be after a change in premium due to reclassification of risk/profitability and/or transmission of message encouraging a change in driving behavior that may result in a re-classification of the risk and predicted profitability (i.e., after the “user management event”), [0045] “…over time…to improve the classification of drivers into separate profit/risk pools”, [0089]-[0098] “determine profitability of a driver, a group of drivers…mileage and speed…classifies profitability/risk…dynamically updating…as more route information is added to the driver profile…can reclassify the risk once additional information is obtained”, [0111] “time periods during which…analyzed for profitability…”, [0134]-[0136] “per time period”)
the second set of operator data comprising (a) a second set of personal data associated with the vehicle operators ([0010]-[0011] “synchronized with the driver’s virtual activity on internet browsers to represent, in the profile of the driver, web sites visited…and physical establishments visited…per time period…plurality of features of the driver including…age, gender, zip code, credit score, type of care driven, and historical infractions…”, [0045] “forms or questionnaires at various points in time and as needed”, [0062] “questionnaire…sent from time-to-time…contribute to the accuracy of the profitability predictions”)
(b) a second set of telematics data comprising a second set of sensor data associated with the vehicle operators via the software…the second set of telematics data in the standardized format ([0011] “driving information…per time period”, [0093] & [0097], [0134]-[0136] “per time period” – above with respect to first set of telematics data for standardized format)
(c) a second set of user management data associated with the vehicle operators ([0011] “…historical claims…associated claims…actual loss and claims data being provided…to correspond more closely to an actual insurance risk as calculated from actual loss and claims data provided over time” – therefore user management data (e.g., historic claim losses) provided over time (e.g., continually during a second time period in addition to a first time period), [0045] “data provided by products and service providers such as actual profitability of drivers…claims data…providing…over time, profitability data such as…claims data for the drivers that have selected their products”, [0136]-[0137] “feedback loop…profitability…losses…claims”)
determining a first set of telematics inferences in the standardized format based at least on the first set of sensor data by using one or more universal predictive models, wherein the first set of telematics inferences are indicative of at least driving characteristics exhibited by the vehicle operators during the first time period, ([0011]-[0013] “classifying the driver into one or more groups…determining an insurance risk (or loss ratio from general expected liability or property claims) for each driver …insurance risk determination can include applying…the driver…risk classification may be presented to a plurality of entities…classification of insurance risks…predicted profitability…” – therefore the system determines a first set of telematics inferences in a standardized format(e.g., risk group for the user, insurance risk, loss ratio) by applying a universal model and the inferences may be accessible to multiple entities via the central sever, [0042] “calculates dynamically profit potential of certain drivers or fleets…for…auto insurance…classify rivers into groups or risk pools based on loss ratio prediction for car or vehicle insurance…can change over time as additional data is captured and processed” – therefore the system determines and continually updates a first set of telematic inferences (e.g., profitability/risk/loss predictions) using the sensor data at least, [0089]-[0098] “determine profitability of a driver, a group of drivers…mileage and speed…algorithm that may be executed by software code residing on the centralized system server”, see also [0134]-[0136])
determining and updating a second set of telematics inferences in the standardized format based at least on the second set of sensor data by using the one or more universal predictive models, wherein the second set of telematics inferences are indicative of at least driving characteristics exhibited by the vehicle operators during the second time period ([0042] “calculates dynamically profit potential of certain drivers or fleets…for…auto insurance…classify rivers into groups or risk pools based on loss ratio prediction for car or vehicle insurance…can change over time as additional data is captured and processed” – therefore the system determines and continually updates a second set of standardized telematic inferences (e.g., profitability/risk/loss predictions) using second sets of data during second time periods, [0045] “…over time, profitability data such as…claims data for the drivers that have selected their products…to improve the classification of drivers into separate profit/risk pools”, [0089]-[0098] “determine profitability of a driver, a group of drivers…mileage and speed…classifies profitability/risk…dynamically updating…as more route information is added to the driver profile…can reclassify the risk once additional information is obtained”, [0111] “time periods during which…analyzed for profitability…”, [0134]-[0136])
determining and updating classification changes based at least on one or more differences between the first set of telematics inferences and the second set of telematics inferences ([0042] “profit potential…classify drivers…classification…can change over time as additional data is captured dynamically and processed”, [0045] “…over time…to improve the classification of drivers into separate profit/risk pools”, [0089]-[0098] “…dynamically updating…as more route information is added to the driver profile…can reclassify the risk once additional information is obtained”, [0011] “classifying the driver into one or more groups…including determining an insurance risk (or loss ratio…for each driver” – loss ratio is a term of art which represents the ratio of claims paid (i.e., predicted costs) to premium earned and therefore the predicted risk/profitability classification comprises one or more ratios of one or more predicted costs to one or more policy premiums)
transmitting the driver classification changes to the marketplace participant ([0011] “risk classification may be presented to a plurality of entities”, [0035] “viewed…profitable segments…allow…insurance companies to…complement their perspective of a particular driver or fleets…with…profitability”, [0042] “profit potential…classify drivers…classification…can change over time as additional data is captured dynamically and processed”, [0055] “presenting the insurance risk classification…”, [0095])
Khoury does not appear to disclose,
wherein the software on the mobile devices/applications is a software development kit (SDK)
determining and updating an event evaluation based at least on one or more differences between the first set of telematics inferences and the second set of telematics inferences
transmitting the event evaluation to the marketplace participant
However, Sadiq discloses a telematics marketplace accessible to a plurality of marketplace participants ([0027]-[0028] & [0031]) that continually and in real-time collects a plurality of sensor data sets and determines one or more telematics inferences ([0030], [0042] “acceleration, braking, cornering, speeding…location, distance…data may be transmitted real-time”) and further discloses tracking telematic inferences before and after a user management event ([0032] “games or objectives may be communicated to drivers, along with an incentive to achieve the objective, in an attempt to…improve or reducing the risks associated with certain driving behaviors” – the system can issue a user challenge to the drivers (and/or “modify a user incentive”) in order to encourage them to decrease their predicted risk, [0038] “determine and/or generate an objective…incentive…tracks performance and determines a result…used to reduce the incidence of loss…insurance carriers and consumers…work toward mutually beneficial goals, including…accident or loss reduction…reduced insurance costs, and/or greater safety…”, [0041] “reducing the number and severity of risky driving behaviors and/or events…”, [0044] “finely graded view…risk level…driver sore and/or vehicle score…motivate the driver to reduce their risk level…”). Sadiq further discloses
determining and updating an event evaluation based at least on one or more differences between the first set of telematics inferences and the second set of telematics inferences ([0038]-[0039] & [0044] & [0055]-[0056] & [0116]-[0118] & [0147]-[0148] & [0154]-[0156] – the user management event (e.g., modified user incentive and/or user challenge and/or modified premium) is used to motivate a driver to modify their risk level/score and the system tracks and analyzes the driver’s telematic inferences before and after the event(s) and determines event evaluations (e.g., an effectiveness of the event) based on the changes between the driver score/metrics/inferences before and after the event in order to determine optimal or most effective user management events for subsequent application and to identify cohorts of users that “demonstrate rapid and sustained improvement in driving behavior” )
transmitting the event evaluation to the marketplace participant ([0056] & [0116]-[0118] & [0147]-[0148] & [0152]-[0156] insurers are provided with the results of the event evaluations so that they can adjust their offerings or incentives/challenges and curate their driver segments and rates)
Sadiq suggests it is advantageous to include determining and updating an event evaluation based at least on one or more differences between the first set of telematics inferences and the second set of telematics inferences, and transmitting the event evaluation to the marketplace participant, because doing so can enable the system to identify optimal or most effective user management events in order to improve the effectiveness of subsequent application of user management events which can help to reduce driving risks and insurance costs and increase insurer profitability and because doing so can help insurers to curate their driver segments and rates (e.g., by identifying cohorts of users that demonstrate rapid and sustained improvement in driving behavior) ([0033] & [0038]-[0039] & [0041] & [0044] & [0053] & [0055]-[0056] & [0118] & [0148]-[0149] & [0154]-[0157]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method, system, and medium of Khoury to include determining and updating an event evaluation based at least on one or more differences between the first set of telematics inferences and the second set of telematics inferences, and transmitting the event evaluation to the marketplace participant, as taught by Sadiq, because doing so can enable the system to identify optimal or most effective user management events in order to improve the effectiveness of subsequent application of user management events which can help to reduce driving risks and insurance costs and increase insurer profitability and because doing so can help insurers to curate their driver segments and rates (e.g., by identifying cohorts of users that demonstrate rapid and sustained improvement in driving behavior).
Furthermore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. One of ordinary skill in the art would have recognized that doing so would enable the system to identify optimal or most effective user management events in order to improve the effectiveness of subsequent application of user management events which can help to reduce driving risks and insurance costs and increase insurer profitability and because doing so can help insurers to curate their driver segments and rates (e.g., by identifying cohorts of users that demonstrate rapid and sustained improvement in driving behavior).
Although Khoury suggests that the first and second sets of telematics data comprising sensor data may be collected from user devices that use a common software program and/or collection code/agent ([0029], [0036]), it is not explicit that this program/code/agent is an SDK. Khoury does not appear to disclose,
wherein the software on the mobile devices/applications is a software development kit (SDK)
However, DriveWell SDK discloses a common SDK that can be commonly installed on multiple mobile devices and/or third-party applications installed on the mobile devices used to collect sensor data (e.g., GPS, barometer, gyroscope, accelerometer) that is normalized and that can be processed using a universal model to generate one or more telematics inferences (e.g., DriveWell scores, such as a Premium score that is an assessment of driver risk to support loss prediction and a Behavioral Score). Also suggests coaching/events that can motivate a user to improve their score over time (i.e., determining first telematics inferences over a first time period and compares them to second telematics inferences over a second time period to determine improvement - “DriveWell Engage”). DriveWell SDK discloses
wherein the software on the mobile devices/applications is a software development kit (SDK) (page 1 of NPL printout “it has to work across thousands of ever-changing phone models and operating systems to accommodate all users…the SDK expertly collects and transforms sensor data…you can deploy the SDK in a fully-featured white-labeled app built by CMT or by integrating it into your own app…no matter the deployment option, you will receive all the benefits of the SDK’s data collection and processing functions” – therefore sets of telematics data comprising sensor data associated with the vehicle operators are collected via a common SDK installed across multiple vehicle operator mobile devices and/or third-part applications installed on the mobile devices and the SDK produces the telematics data in a standardized format across the devices because the SDK is the same and configured to transmit the data to the central repository for common analysis/processing, page 7 “gathers sensor data from millions of IoT devices – including smartphones…connected vehicles…third-party devices…creates a unified view of vehicle and driver behavior. Auto insurers, automakers, commercial mobility companies, and the public sector use insights from CMT’s platform to power risk assessment…and driver improvement programs”, page 10 a solution that meets the unique needs of all of our partners…a user-forward mobile telematics program…DriveWell SDK…Collect meaningful sensor data and harness CMT’s expertise in your own app…measure driver risk with scoring models based on millions of trips and billions of miles…” )
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself. That is in the substitution of the common SDK (which therefore results in data having standard format across devices/vehicles) of DriveWell SDK for the common software program and/or collection code/agent of Khoury in view of Sadiq. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Using localized software programs and/or collection code/agent is a key factor in the success of a system that collects telematics/sensor data at a remote computing system/server. As discussed by DriveWell SDK, an SDK is one of several known types of localized software programs and/or collection code/agents that enables devices/computers to communicate information to a central location/server. This practice is well known in the business community and would follow in Khoury in view of Sadiq. Therefore, it would have been obvious to try, by one of ordinary skill in the art at the time of the invention, to modify Khoury in view of Sadiq to use a common SDK (which therefore results in data having standard format across devices/vehicles) as the localized software programs and/or collection code/agent, since there are a finite number of identified, predictable potential solutions (i.e., types of localized software programs and/or collection code/agent) to the recognized need (use localized software programs and/or collection code/agent to gather, format, and transmit the data) and one of ordinary skill in the art would have pursued the known potential solutions with a reasonable expectation of success (the costs and benefits were known).
With respect to claims 2, 11, and 20, Khoury teaches the method of claim 1, the system of claim 10, and the medium of claim 19;
wherein determining the first set of telematics inferences comprises determining a first predicted profitability based at least on the first set of personal data and the first set of sensor data, and ([0013] “classifying the driver into one or more groups…predicted profitability potential …”, [0028] “predict…profitability of drivers or fleets…classify the potential profitability of certain individuals or groups of individuals or fleets of vehicles…”, [0042] “calculates dynamically profit potential of certain drivers or fleets…for…auto insurance…classify rivers into groups or risk pools based on loss ratio prediction for car or vehicle insurance…can change over time as additional data is captured and processed”, [0134]-[0136]))
the determining and updating the second set of telematics inferences includes determining and updating a second predicted profitability based at least on the second set of personal data and the second set of sensor data ([0042] “calculates dynamically profit potential of certain drivers or fleets…for…auto insurance…classify rivers into groups or risk pools based on loss ratio prediction for car or vehicle insurance…can change over time as additional data is captured and processed” – therefore the system determines and continually updates the telematic inferences (e.g., profitability/risk/loss predictions) using second sets of data during second time periods, [0134]-[0136] “per time period…the profitability can be revised further…feedback loop…over time…risk pool…”, [0013] “classifying the driver into one or more groups…predicted profitability potential …”, [0028] “predict…profitability of drivers or fleets…classify the potential profitability of certain individuals or groups of individuals or fleets of vehicles…”)
With respect to claims 3 and 12, Khoury teaches the method of claim 2, and the system of claim 11.
wherein, the determining updating the driver classification changes comprises determining and updating one or more differences between the first predicted profitability and the second predicted profitability ([0042] “calculates dynamically profit potential of certain drivers or fleets…for…auto insurance…classify rivers into groups or risk pools based on loss ratio prediction for car or vehicle insurance…can change over time as additional data is captured and processed” – therefore the system determines and continually updates the telematic inferences (e.g., profitability/risk/loss predictions) using second sets of data during second time periods, [0134]-[0136] “per time period…the profitability can be revised further…feedback loop…over time…risk pool…”, [0013] “classifying the driver into one or more groups…predicted profitability potential …”, [0028] “predict…profitability of drivers or fleets…classify the potential profitability of certain individuals or groups of individuals or fleets of vehicles…”)
Khoury does not appear to disclose,
wherein determining and updating the event evaluation comprises determining and updating one or more differences between the first predicted profitability and the second predicted profitability
However, as discussed above with respect to claims 1, 10, and 19, Sadiq discloses comparing predicted risk and/or vehicle/driver score (and/or other telemetry metrics) before and after a user management event in order to determine/update an event evaluation ([0038]-[0039] & [0044] & [0055]-[0056] & [0116]-[0118] & [0147]-[0148] & [0154]-[0156] – the user management event (e.g., modified user incentive and/or user challenge and/or modified premium) is used to motivate a driver to modify their risk level/score and the system tracks and analyzes the driver’s telematic inferences before and after the event(s) and determines event evaluations (e.g., an effectiveness of the event) based on the changes between the driver score/metrics/inferences before and after the event in order to determine optimal or most effective user management events for subsequent application and to identify cohorts of users that “demonstrate rapid and sustained improvement in driving behavior” ), and that one of the goals of doing so is to decrease costs/losses for an insurer. As such, it would have been obvious to apply the teachings of Sadiq to the method and system of Khoury to compare the predicted profitability for each driver group/fleet (e.g., in addition to and/or instead of comparing a driver risk level/score or other risk/cost-related metric) as doing so would achieve the same outcome of reducing driving risks and insurance costs and increasing insurer profitability, and because the predicted profitability is merely one of several available telemetric inferences tied to risk and cost/loss.
With respect to claims 4 and 13, Khoury teaches the method of claim 1, and the system of claim 10
wherein the determining the first set of telematics inferences comprises determining a first predicted costs and a first predicted expenses based at least on the first set of personal data and the first set of sensor data, and ([0011] “classifying the driver into one or more groups…determining…loss ratio from general expected liability or property claims…associated claims…actual loss and claims data…” & [0042] “can also classify drivers…based on loss ratio prediction…” & [0045] “estimated loss ratio for future insurance at various rate levels” & [0089]-[0090] “system can determine the profitability of a driver, a group of drivers…determine a driver risk and set corresponding premiums. The classification of risks determines the premiums paid…or the amount of expenses, such as commission expenses, that can be paid for the same premium. If a risk is in a lower risk class…can profitably pay higher commissions or pay higher promotional or advertising expenses to acquire that business…underwriting factors…type of cars…age, zip code…credit score…mileage and speed…direct influence on the insurance risk…predictor of the economics of the insurance cost, especially when combined with…demographics…” & [0095] “access to a profit segmented base of drivers or fleets” & [0135]-[0136] “feedback loop provides actual profitability…using those actual values…loss ratio…claims…the cost potential claim…predictors of the future insurance cost (loss ratio) and the intermediary cost…weight…feedback loop of actual claims…revised weights…predictor of the claims” – the system predicts a profitability of each user or group of users and as part of this the system determines and continually updates one or more predicted costs and comparing the changes in profitability/risk classification therefore comprises determining a one or more differences between predicted costs between time periods)
the determining and updating the second set of telematics inferences comprises determining and updating a second predicted costs and a second predicted expenses based at least on the second set of personal data and the second set of sensor data ([0011] “classifying the driver into one or more groups…determining…loss ratio from general expected liability or property claims…associated claims…actual loss and claims data…” & [0042] “can also classify drivers…based on loss ratio prediction…” & [0045] “estimated loss ratio for future insurance at various rate levels” & [0089]-[0090] “system can determine the profitability of a driver, a group of drivers…determine a driver risk and set corresponding premiums. The classification of risks determines the premiums paid…or the amount of expenses, such as commission expenses, that can be paid for the same premium. If a risk is in a lower risk class…can profitably pay higher commissions or pay higher promotional or advertising expenses to acquire that business…underwriting factors…type of cars…age, zip code…credit score…mileage and speed…direct influence on the insurance risk…predictor of the economics of the insurance cost, especially when combined with…demographics…” & [0095] “access to a profit segmented base of drivers or fleets” & [0135]-[0136] “feedback loop provides actual profitability…using those actual values…loss ratio…claims…the cost potential claim…predictors of the future insurance cost (loss ratio) and the intermediary cost…weight…feedback loop of actual claims…revised weights…predictor of the claims” – the system predicts a profitability of each user or group of users and as part of this the system determines and continually updates one or more predicted expenses and comparing the changes in profitability/risk classification therefore comprises determining a one or more differences between predicted expenses between time periods)
With respect to claims 5 and 14, Khoury teaches the method of claim 4 and the system of claim 13
wherein, the determining and updating the driver classification changes includes: determining and updating one or more differences between the first predicted costs and the second predicted costs ([0011] “classifying the driver into one or more groups…determining…loss ratio from general expected liability or property claims…associated claims…actual loss and claims data…” & [0042] “can also classify drivers…based on loss ratio prediction…” & [0045] “estimated loss ratio for future insurance at various rate levels” & [0089]-[0090] “system can determine the profitability of a driver, a group of drivers…determine a driver risk and set corresponding premiums. The classification of risks determines the premiums paid…or the amount of expenses, such as commission expenses, that can be paid for the same premium. If a risk is in a lower risk class…can profitably pay higher commissions or pay higher promotional or advertising expenses to acquire that business…underwriting factors…type of cars…age, zip code…credit score…mileage and speed…direct influence on the insurance risk…predictor of the economics of the insurance cost, especially when combined with…demographics…” & [0095] “access to a profit segmented base of drivers or fleets” & [0135]-[0136] “feedback loop provides actual profitability…using those actual values…loss ratio…claims…the cost potential claim…predictors of the future insurance cost (loss ratio) and the intermediary cost…weight…feedback loop of actual claims…revised weights…predictor of the claims” – the system predicts a profitability of each user or group of users and as part of this the system determines and continually updates one or more predicted costs and comparing the changes in profitability/risk classification therefore comprises determining a one or more differences between predicted costs between time periods)
determining and updating one or more differences between the first predicted expenses and the second predicted expenses ([0011] “classifying the driver into one or more groups…determining…loss ratio from general expected liability or property claims…associated claims…actual loss and claims data…” & [0042] “can also classify drivers…based on loss ratio prediction…” & [0045] “estimated loss ratio for future insurance at various rate levels” & [0089]-[0090] “system can determine the profitability of a driver, a group of drivers…determine a driver risk and set corresponding premiums. The classification of risks determines the premiums paid…or the amount of expenses, such as commission expenses, that can be paid for the same premium. If a risk is in a lower risk class…can profitably pay higher commissions or pay higher promotional or advertising expenses to acquire that business…underwriting factors…type of cars…age, zip code…credit score…mileage and speed…direct influence on the insurance risk…predictor of the economics of the insurance cost, especially when combined with…demographics…” & [0095] “access to a profit segmented base of drivers or fleets” & [0135]-[0136] “feedback loop provides actual profitability…using those actual values…loss ratio…claims…the cost potential claim…predictors of the future insurance cost (loss ratio) and the intermediary cost…weight…feedback loop of actual claims…revised weights…predictor of the claims” – the system predicts a profitability of each user or group of users and as part of this the system determines and continually updates one or more predicted expenses and comparing the changes in profitability/risk classification therefore comprises determining a one or more differences between predicted expenses between time periods)
Khoury does not appear to disclose,
wherein, the determining and updating the event evaluation comprises determining and continually updating one or more differences between the first predicted costs and the second predicted costs, and determining and updating one or more differences between the first predicted expenses and the second predicted expenses
However, as discussed above with respect to claims 1, 10, and 19, Sadiq discloses comparing predicted risk and/or vehicle/driver score (and/or other telemetry metrics) before and after a user management event in order to determine/update an event evaluation ([0038]-[0039] & [0044] & [0055]-[0056] & [0116]-[0118] & [0147]-[0148] & [0154]-[0156] – the user management event (e.g., modified user incentive and/or user challenge and/or modified premium) is used to motivate a driver to modify their risk level/score and the system tracks and analyzes the driver’s telematic inferences before and after the event(s) and determines event evaluations (e.g., an effectiveness of the event) based on the changes between the driver score/metrics/inferences before and after the event in order to determine optimal or most effective user management events for subsequent application and to identify cohorts of users that “demonstrate rapid and sustained improvement in driving behavior” ), and that one of the goals of doing so is to decrease costs/losses and increase margins for an insurer. As such, it would have been obvious to apply the teachings of Sadiq to the method and system of Khoury to compare the predicted profitability for each driver group/fleet (e.g., in addition to and/or instead of comparing a driver risk level/score or other risk/cost-related metric, and which comprises a comparison of costs and expenses as profitability is dependent on these values) as doing so would achieve the same outcome of reducing driving risks and insurance costs and increasing insurer profitability, and because the predicted profitability is merely one of several available telemetric inferences tied to risk and cost/loss.
With respect to claims 6 and 15, Khoury teaches the method of claim 1, and the system of claim 10
wherein, the first set of sensor data and the second set of sensor data are collected via one or more sensors used by mobile applications ([0036]-[0037] “mobile device associated with a specific driver…code…collecting driving information…device GPS, and device local sensors…various local sensors…” , see also Fig 3 & [0029] & [0045] – Examiner notes DrieWell SDK also discloses this feature as discussed above with respect to claims 1 and 10)
each vehicle operator of the vehicle operators uses at least one mobile application of the mobile applications ([0036]-[0037] “mobile device associated with a specific driver…code…collecting driving information…device GPS, and device local sensors…various local sensors…” , see also Fig 3 & [0029] & [0045] - Examiner notes DrieWell SDK also discloses this feature as discussed above with respect to claims 1 and 10)
Examiner notes Sadiq also discloses this limitation.
With respect to claims 7 and 16, Khoury teaches the method of claim 1, and the system of claim 10;
wherein, the management event includes modifying a policy premium, modifying a risk allowance, modifying a user incentive, or issuing a user challenge ([0049] “system can send targeted messages to the mobile device of the driver encouraging changes in driving behavior that may result in a re-classification of the risk and predicted profitability…” – equivalent to “issuing a user challenge”, [0089] “the classification…determines the premiums paid” – therefore an insurer may adjust a user’s premium if they are classified into a lower risk or higher profitability group which is a “user management event”)
Examiner notes Sadiq also discloses wherein the management event includes modifying a policy premium, modifying a risk allowance, modifying a user incentive, or issuing a user challenge ([0032] “games or objectives may be communicated to drivers, along with an incentive to achieve the objective, in an attempt to…improve or reducing the risks associated with certain driving behaviors” – the system can issue a user challenge to the drivers (and/or “modify a user incentive”) in order to encourage them to decrease their predicted risk, [0038] “determine and/or generate an objective…incentive…tracks performance and determines a result…used to reduce the incidence of loss…insurance carriers and consumers…work toward mutually beneficial goals, including…accident or loss reduction…reduced insurance costs, and/or greater safety…”, [0041] “reducing the number and severity of risky driving behaviors and/or events…”, [0044] “finely graded view…risk level…driver sore and/or vehicle score…motivate the driver to reduce their risk level…”).
With respect to claims 8 and 17, Khoury teaches the method of claim 7, and the system of claim 16;
wherein, the first set of user management data and the second set of user management data comprise historic customer service expenses associated with the vehicle operators, historic user experience costs associated with the vehicle operators, historic user acquisition costs associated with the vehicle operators, historic user retention costs associated with the vehicle operators, historic claim losses associated with the vehicle operators, or historic referral revenue associated with the vehicle operators ([0011] “loss ratio from general expected liability or property claims…historical claims…associated claims…actual loss and claims data being provided to cause the determined insurance risk…to correspond more closely to an actual insurance risk as calculated from actual loss and claims data provided over time” – therefore the system obtains historic claim losses to determine/predict loss ratio and risk/profitability, [0035] “total cost from accident and liability claims”, [0045] “data provided by products and service providers such as actual profitability of drivers…claims data”, [0135]-[0137] “feedback loop provides actual profitability…using those actual values…loss ratio…claims…the cost potential claim…predictors of the future insurance cost (loss ratio) and the intermediary cost…weight…feedback loop of actual claims…revised weights…predictor of the claims”)
With respect to claims 9 and 18, Khoury teaches the method of claim 1, and the system of claim 10;
wherein, the one or more differences between the first set of telematics inferences and the second set of telematics inferences comprises one or more differences in reliability scores for the vehicle operators, financial stability scores for the vehicle operators, financial reliability scores for the vehicle operators, demographic scores for the vehicle operators, mobility scores for the vehicle operators, predicted risk scores for the vehicle operators, predicted costs scores for the vehicle operators, predicted retention scores for the vehicle operators, or payment reliability scores for the vehicle operators ([0013] “classifying the driver into one or more groups…predicted profitability potential …”, [0028] “predict…profitability of drivers or fleets…classify the potential profitability of certain individuals or groups of individuals or fleets of vehicles…”, [0042] “calculates dynamically profit potential of certain drivers or fleets…for…auto insurance…classify rivers into groups or risk pools based on loss ratio prediction for car or vehicle insurance…can change over time as additional data is captured and processed” – therefore determines a difference between at least profitability score and/or predicted risk/cost scores, [0134]-[0136]))
Examiner notes Sadiq and DriveWell SDK also disclose this limitation
Prior Art of Record
The prior art made of record and not relied upon is considered pertinent to the applicant’s disclosure.
Follmer et al. (U.S. PG Pub No. 2009/0024273, January 22, 2009) teaches capturing and processing real-time vehicle telematic data to derive various metrics (e.g., letter grade, percentage, more general category) and updating individual driver profiles. Provides a central marketplace where various entities can access the data, and where insurers can bid to provide insurance to certain groups/tiers of driver profiles.
Boccon-Gibod (U.S. PG Pub No. 2014/0129599 May 8, 2014) teaches capturing and processing real-time vehicle telematic data to derive various metrics and wherein the data is collected via a common SDK in a common format ([0047]-[0048] & [0056]-[0059] & [0029]-[0032])
Salodkar et al. (U.S. Patent No. 10,997,800 May 4, 2021 - hereinafter ''Salodkar’’) teaches capturing and processing real-time vehicle telematic data to derive various metrics and wherein the data is collected via a common SDK in a common format ([0047]- [0048] & [0056]-[0059] & [0029]-[0032]).
Altieri (U.S. PG Pub No. 2012/0084103 - hereinafter "Altieri”) discloses a telematics marketplace accessible to a plurality of marketplace participants that continually collects a plurality of personal data sets and sensor data sets and determines one or more primary telematics inferences (e.g., standardized/generalized driver safety score and/or various abstract scores.
Burge (U.S. PG Pub No. 2002/0111725 August 15, 2002 - hereinafter "Burge”) discloses a telematics marketplace accessible to a plurality of marketplace participants ([0144]-[0147]) that continually collects a plurality of personal data sets and sensor data sets and determines one or more primary telematics inferences (e.g., standardized/generalized driver safety score and/or various abstract scores per [0185] & [0200]-[0201] & [0203], see also [0197] & [0208]).
McClellan et al. (U.S. PG Pub No. 2009/0024419 January 22, 2009- hereinafter "McClellan”) teaches capturing and processing real-time vehicle telematic data to derive various metrics (e.g., letter grade, percentage, more general category) and updating individual driver profiles. Provides a central marketplace where various entities can access the data, and where insurers can bid to provide insurance to certain groups/tiers of driver profiles.
Hibler et al. (U.S. PG Pub No. 2019/0311438 October 10, 2019) teaches party-specific telematic metric models used in a data marketplace ([0020] & [0040])
Bischoff et al. (U.S. Patent No. 10,109,014, October 23, 2018) teaches calculating various driver metrics based on telematics data and personal data using various models. Teaches a profitability model used to predict profitability of specific drivers which incorporates a retention/acquisition model used to predict the revenue for a driver (e.g., premium they would accept) based on price elasticity that is informed based on tracked offer acceptances/rejections.
Rosauer et al. (U.S. PG Pub No. 2007/0016542 January 18, 2007) teaches training and using various models to analyze driving information in order to assign single scores representing predicted profitability to individual drivers, including predicted losses, costs, revenue, and retention. The scores are used in underwriting decisions.
Drucker et al. (U.S. PG Pub No. 2019/0156426 May 23, 2019) teaches collecting user data sets from third parties, including social media activity, browsing data, etc., to use when scoring individual cost/loss predictions. The risk/cost/loss scores are used in underwriting decisions.
Taylor et al. (U.S. PG Pub No. 2010/0030586, February 4, 2010) teaches continually capturing driver personal data sets (e.g., from third parties) and telematic data sets and continually processing the data to derive various driver metrics and risk/loss scores. Discloses providing a central marketplace that can field requests for information/profiles/scores from insurers or other parties and responsively provide the information.
Rippel et al. (U.S. PG Pub No. 2010/0030582, February 4, 2010) teaches a central data marketplace that collects vehicle telematics data and personal data sets from various third parties and calculates a comprehensive driver score (as well as various sub-scores) based on the information using a universal model. Insurers and other parties can request profile information or driver scores from the marketplace in connection with underwriting decisions.
Freiberger et al. (U.S. PG Pub No. 2014/0058761, February 27, 2014) teaches a central data marketplace that collects raw telematics data from vehicles in real-time and continuously updates driver metrics (e.g., performance/risk metrics correlated to cost/loss based on the driver’s risk profile). Offers a plurality of pre-approved (e.g., from regulators) universal scoring models from which insurers may select/opt to use. Insurers may obtain risk/cost scores for different types of drivers, and may bid to provide insurance to certain groups of drivers.
Rackley III et al. (U.S. PG Pub No. 2020/0065908 February 27, 2020) teaches party-specific telematic metric models used in a data marketplace.
“Usage-Based Insurance and Vehicle Telematics: Insurance Market and Regulatory Implications”; Karapiperis, Dimitris et al., March 2015; published by the NAIC National Association of Insurance Commissioners & the Center for Insurance Policy Research (available at http://www.naic.org/cipr_special_reports.htm) teaches training and using various models to analyze driving information in order to assign scores representing predicted losses/risk etc., to individual drivers. The scores are used in underwriting decisions.
Conclusion
No claim is allowed
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES M DETWEILER whose telephone number is (571)272-4704. The examiner can normally be reached on Monday-Friday from 8 AM to 5 PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Waseem Ashraf can be reached at telephone number (571)-270-3948. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/JAMES M DETWEILER/Primary Examiner, Art Unit 3621
Prosecution Insights