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 personal data sets associated with vehicle operators associated with marketplace participants;
collecting telematics data sets for the vehicle operators…wherein the collecting of the telematics data sets comprises collecting sensor data sets associated with the vehicle operators via sensors, and wherein the sensor data sets comprise at least one of location sensor data, orientation sensor data, acceleration sensor data, or velocity sensor data;
for each vehicle operator of the vehicle operators: producing…a telematics data set of the telematics data sets in a standardized format, wherein the telematics data set in the standardized format comprises a sensor data set of the sensor data sets associated with the vehicle operator in the standardized format;
determining and updating one or more telematics inferences in the standardized format based at least on the telematics data set in the standardized format by using one or more universal predictive models;
generating and updating an operator profile comprising a personal data set of the personal data sets associated with the vehicle operator;
generating and updating a data profile associated with the vehicle operator, wherein the data profile comprises the sensor data set in the standardized format and the one or more telematics inferences in the standardized format;
assigning and updating an operator tier selected from operator tiers based at least on the one or more telematics inferences; and
listing and updating the data profile onto a telematics marketplace according to the operator tier to be accessible by the marketplace participants;
receiving, from a requesting party of the marketplace participants, an information request for one or more operator profiles associated with a number of vehicle operators of a target operator tier selected from the operator tiers; and
transmitting, in response to the information request, the one or more operator profiles to the requesting party
These steps, under its broadest reasonable interpretation, describe or set-forth collecting/gathering a variety of data associated with vehicle operators (e.g., personal data, telematics data), deriving one or more telematic inferences (e.g., metrics/scores, such as profitability scores), generating and updating an operator profile for each vehicle operator (comprising personal data of an operator), generating and updating a data profile associated with each the vehicle operator (comprising the sensor data set in the standardized format and the one or more telematics inferences in the standardized format), assigning and updating an operator tier selected from operator tiers based at least on the one or more telematics inferences; listing and updating the data profile onto a telematics marketplace according to the operator tier to be accessible by the marketplace participants (e.g., insurers); and transmitting, in response to the information request, the one or more operator profiles to the requesting party, 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)
“telematics data sets…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, …by the SDK …” (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 “telematics data sets…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, …by the SDK …” (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 “telematics data sets…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, …by the SDK …” (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 telematics data sets for 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, wherein the collecting of the telematics data sets comprises collecting sensor data sets associated with the vehicle operators via sensors, and wherein the sensor data sets comprise at least one of location sensor data, orientation sensor data, acceleration sensor data, or velocity sensor data” (claims 1, 10, and 19) and/or “transmitting, in response to the information request, the one or more operator profiles to the requesting party “ (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 telematic inferences and generating operator/data profiles of vehicle operators, assigning operator tiers, and sharing this information with interested parties (e.g., insurers)). 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 determining and updating the one or more telematics inferences comprises: determining and updating a predicted profitability based at least on the personal data set and the sensor data set.”. 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 “telematics data sets…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, …by the SDK …” (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 “telematics data sets…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, …by the SDK …” (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 telematics data sets for 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, wherein the collecting of the telematics data sets comprises collecting sensor data sets associated with the vehicle operators via sensors, and wherein the sensor data sets comprise at least one of location sensor data, orientation sensor data, acceleration sensor data, or velocity sensor data” (claims 1, 10, and 19) and/or “transmitting, in response to the information request, the one or more operator profiles to the requesting party “ (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 “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 personal data sets associated with vehicle operators associated with marketplace participants; ([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])
collecting telematics data sets for 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 collecting of the telematics data sets comprises collecting sensor data sets associated with the vehicle operators via sensors, and wherein the sensor data sets comprise at least one of location sensor data, orientation sensor data, acceleration sensor data, or velocity sensor data; ([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)
for each vehicle operator of the vehicle operators: producing…a telematics data set of the telematics data sets in a standardized format, wherein the telematics data set in the standardized format comprises a sensor data set of the sensor data sets associated with the vehicle operator in the standardized format; ([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)
determining and updating one or more telematics inferences in the standardized format based at least on the telematics data set in the standardized format by using one or more universal predictive models; ([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])
generating and updating an operator profile comprising a personal data set of the personal data sets associated with the vehicle operator; ([0010]-[0011] “a profile of the driver can be created based on the driver's use of the mobile device…Socio-demographic or potential interests for products and services can be associated with the profile of the driver…The driver's activity on the mobile device…can be synchronized with the driver's virtual activity on internet browsers to represent, in the profile of the driver, web sites visited using the browser and physical establishments visited or driven by that are associated with the typical route segment…features of the driver…age, gender, zip code, credit score, type of car driven…”, [0030] “centralized database of driver profiles…demographics…”, [0045]-[0046] “ The server 307a hosts a driver profile and a profit or risk profile database 307b and the interest or demographics database 307c where factors affecting the profitability of several products are stored”, see also [0060] & [0067] & [0073]-[0077] & [0088] for profile comprising personal data set)
generating and updating a data profile associated with the vehicle operator, wherein the data profile comprises the sensor data set in the standardized format and the one or more telematics inferences in the standardized format; ([0007]-[0008] “storing, in a database associated with the server, an identifier associated with the driver and the encoded driving information, (iii) determining, and storing in the database, predicted future typical route segments that the driver is likely to travel over a certain period of time and associated times of day based on the encoded driving information, and (iv) classifying the driver into one or more groups based on the encoded driving information….collects driving information, where the driving information can include routes driven by the driver in the vehicle, geocoded locations, mileage, times of day, and speeds,…The database stores an identifier associated with the driver, the encoded driving information, and predicted future typical route segments that the driver is likely to travel over a certain period of time and associated times of day based on the encoded driving information. The processor is associated with the server and is in communication with the database and the device. The processor determines the predicted future typical route segments and classifies the driver into one or more groups based on the encoded driving information.”, [0010]-[0011] “a profile of the driver can be created based on the driver's…encoded driving information…classifying the driver into one or more groups…determining an insurance risk (or loss ratio…for each driver…routes driven…driving behavior…speed…”, [0030] “centralized database of driver profiles…driving patterns, mileage…speed…areas traveled through…profitability classification”, ([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…”, [0045]-[0046] “ The server 307a hosts a driver profile and a profit or risk profile database 307b and the interest or demographics database 307c where factors affecting the profitability of several products are stored…average speed…The Profile database 307c may contain the classifications”, [0093] “classifies profitability/risk for certain products and services using first partial route information and then dynamically updating the risk classification as more route information is added to the driver profile”, see also [0068]-[0073] & [089] & [0097] & [0134]-[0136] for data profile of each operator comprising the sensor data and one or more telematics inferences)
assigning and updating an operator tier selected from operator tiers based at least on the one or more telematics inferences; and ([0003]-[0004] “clearinghouse exchange system can classify drivers into profitability classes…provide a profit potential classification of a driver…”, [0007] “collecting driving information and classifying drivers…the driving information can include routes driven in the vehicle, geocoded locations, mileage, times of day, and speeds…classifying the driver into one or more groups based on the encoded driving information”, [0011] “classifying the driver into one or more groups based on the encoded driving information includes determining an insurance risk (or loss ratio from general expected liability or property claims) for each driver…the insurance risk determination can include applying (i) a plurality of features of the routes driven including, for example, mileage (cumulative or per time period), speed (as compared to speed limit for each road segment), types of roads driven (e.g., highway versus city), types of areas driven through (high risk areas with high historical claims), or zip codes, and (ii) a plurality of features of the driver including, for example, historical routes driven, driving behavior, times of day, age, gender, zip code, credit score, type of car driven, and historical infractions”, [0013] “classifying the driver into one or more groups can include classifying the driver according to a predicted profitability potential…based on the encoded driving information”, [0042] “can also classify drivers into groups or risk pools based on loss ratio prediction for car or vehicle insurance as predicted by the routes driven and other data captured by the system. The classification is dynamic in that it can change over time as additional data is captured dynamically and processed by the interactive system 300.”, see also [0045] & [0049] &[0053] & [0073] & [0093])
listing and updating the data profile onto a telematics marketplace according to the operator tier to be accessible by the marketplace participants; ([0011] “The driver or underlying driving technology insurance risk classification may be presented to a plurality of entities…”, [0055] “determining 660 an insurance risk for each driver or fleet of self-driven or partially self-driven vehicles based on driving information of the driver or fleet of self-driven or partially self-driven vehicles (e.g., driving information collected by the above example method 500). The method 650 further includes presenting 665 the insurance risk classification to a plurality of entities”), [0025] “centralized database of key profitability parameters…the database can be leveraged across all players in a specific industry. Such a database can be viewed as an industry utility organization for the purpose of better targeting profitable segments of a particular market or declining high risk individuals”,
receiving, from a requesting party of the marketplace participants, an information request for one or more operator profiles associated with a number of vehicle operators of a target operator tier selected from the operator tiers; and ([0011] “The driver or underlying driving technology insurance risk classification may be presented to a plurality of entities, requests may be received from at least one of the entities…to drivers within a specific risk classification…provide insurance for or offer services to the driver”– therefore the system can receive an information request for one or more operator profiles from a requesting party of the marketplace participants associated with a number of vehicle operators of a target operator tier selected from the operator tiers, [0056] “some of the product and service providers are requesting access to the most profitable segments for promotional activities”, [0025] “centralized database of key profitability parameters…the database can be leveraged across all players in a specific industry. Such a database can be viewed as an industry utility organization for the purpose of better targeting profitable segments of a particular market or declining high risk individuals”, [0045] “an insurance carrier data provider…specific groups of profit/risk classified drivers associated to their vehicles 310b… fees they would be willing to pay) to access the database 307b to market specific wireless data to specific profit/risk classified driver groups, )
transmitting, in response to the information request, the one or more operator profiles to the requesting party ([0055] “determining 660 an insurance risk for each driver or fleet of self-driven or partially self-driven vehicles based on driving information of the driver or fleet of self-driven or partially self-driven vehicles (e.g., driving information collected by the above example method 500). The method 650 further includes presenting 665 the insurance risk classification to a plurality of entities”), [0011] “The driver or underlying driving technology insurance 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”, [0095])
Although Khoury suggests that the telematics data sets 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)…by the 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)…by the 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. 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. 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 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 and updating the one or more telematics inferences comprises determining and updating a predicted profitability based at least on personal data set and the sensor data set ([0013] “classifying the driver into one or more groups…predicted profitability potential …”, [0007] “collecting driving information and classifying drivers…the driving information can include routes driven in the vehicle, geocoded locations, mileage, times of day, and speeds…classifying the driver into one or more groups based on the encoded driving information”, [0011] “classifying the driver into one or more groups based on the encoded driving information includes determining an insurance risk (or loss ratio from general expected liability or property claims) for each driver…the insurance risk determination can include applying (i) a plurality of features of the routes driven including, for example, mileage (cumulative or per time period), speed (as compared to speed limit for each road segment), types of roads driven (e.g., highway versus city), types of areas driven through (high risk areas with high historical claims), or zip codes, and (ii) a plurality of features of the driver including, for example, historical routes driven, driving behavior, times of day, age, gender, zip code, credit score, type of car driven, and historical infractions”, [0013] “classifying the driver into one or more groups can include classifying the driver according to a predicted profitability potential…based on the encoded driving information”, [0042] “can also classify drivers into groups or risk pools based on loss ratio prediction for car or vehicle insurance as predicted by the routes driven and other data captured by the system. The classification is dynamic in that it can change over time as additional data is captured dynamically and processed by the interactive system 300.”, see also [0045] & [0049] &[0053] & [0073] & [0093]) [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]))
With respect to claims 3 and 12, Khoury teaches the method of claim 2, and the system of claim 11.
wherein assigning and updating the operator tier comprises: assigning and updating a predicted operator profitability tier selected from predicted operator profitability tiers based at least on the predicted profitability. ([0011] “classifying the driver into one or more groups based on the encoded driving information includes determining an insurance risk (or loss ratio from general expected liability or property claims) for each driver…the insurance risk determination can include applying (i) a plurality of features of the routes driven including, for example, mileage (cumulative or per time period), speed (as compared to speed limit for each road segment), types of roads driven (e.g., highway versus city), types of areas driven through (high risk areas with high historical claims), or zip codes, and (ii) a plurality of features of the driver including, for example, historical routes driven, driving behavior, times of day, age, gender, zip code, credit score, type of car driven, and historical infractions”, [0013] “classifying the driver into one or more groups can include classifying the driver according to a predicted profitability potential…based on the encoded driving information”, [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 4 and 13, Khoury teaches the method of claim 2, and the system of claim 11
wherein determining and updating the predicted profitability comprises: determining and updating predicted costs based at least on the personal data set and the sensor data set. ([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)
With respect to claims 5 and 14, Khoury teaches the method of claim 4 and the system of claim 13
wherein assigning and updating the operator tier comprises: assigning and updating a predicted operator costs tier selected from predicted operator costs tiers based at least on the 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)
With respect to claims 6 and 15, Khoury teaches the method of claim 4, and the system of claim 13
wherein, determining and updating the predicted costs comprises: determining and updating predicted losses and predicted expenses based at least on the personal data set and the sensor data set. ([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)
With respect to claims 7 and 16, Khoury teaches the method of claim 6, and the system of claim 15;
wherein assigning and updating the operator tier comprises: assigning and updating a predicted operator losses tier selected from predicted operator losses tiers based at least on the predicted losses; and assigning and updating a predicted operator expenses tier selected from predicted operator expenses tiers based at least on the 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 costs and comparing the changes in profitability/risk classification therefore comprises determining a one or more differences between predicted costs between time periods)
With respect to claims 8 and 17, Khoury teaches the method of claim 1, and the system of claim 10;
wherein: the sensors are operated by mobile applications; and each vehicle operator uses at least one mobile application of the mobile applications ([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…”, [0036] “an 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…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”, [0038] “a message may appear on the device asking if the user of the application is driving his own vehicle”, [0048], [0077])
Examiner notes DriveWell SDK also discloses this limitation
With respect to claims 9 and 18, Khoury teaches the method of claim 8, and the system of claim 17;
wherein the mobile applications comprise one or more of a system software application, an entertainment software application, a gaming software application, a navigation software application, or an environment software application. ([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…” – at least a system software application, [0038] “a message may appear on the device asking if the user of the application is driving his own vehicle”, [0058] “turn-by-turn navigation application”, [0048], [0077])
Examiner notes DriveWell SDK also discloses this limitation.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/forms/. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
v Claims 1-20 are rejected on the ground of non-statutory anticipation-type double patenting as being unpatentable over claims 1-20 of US Patent No. 12,367,507 (corresponding to co-pending US Application No. 18/065,847). Although the conflicting claims are not identical, they are not patentably distinct from each other. Each of the instant claims is anticipated by at least one claim of US Patent No. 12,367,507. The exact limitations of each of these claims are not being reproduced here for clarity and brevity, as the Examiner believes the anticipation would be self-evident to a PHOSITA.
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.
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. Discloses receiving a request for one or more operator profiled associated with a number of vehicle operators of a target operator tier, and transmitting the one or more operator profiles to the requesting party.
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]).
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