DETAILED ACTION
Status of the Application
In response filed on January 9, 2026, the Applicant amended claims 1, 2, 4, 5, 11, 12, 16, and 17. Claims 1-20 are pending and currently under consideration for patentability.
Priority
The instant application has a filing date of July 25, 2024, and claims for the benefit of prior-filed provisional application # 63/604,729 (filed on November 30, 2023) and for the benefit of prior-filed provisional application # 63/589,785 (filed on October 12, 2023). Applicant’s claim for the benefit of these prior-filed provisional applications is acknowledged.
The instant application also claims for the benefit of prior-filed provisional application # 63/421,723 (filed on November 2, 2022). However, the instant application was filed more than 12 months after the date on which provisional application # 63/421,723 was filed. As such, the instant application was not filed during the permitted pendency of the provisional application, and is therefore not entitled to the benefit of the filing date of this provisional application (See MPEP section 211).
The earliest filing date to which the present application is entitled is therefore October 12, 2023 (the filing date of provisional application # 63/589,785).
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 .
Response to Amendments and Arguments
v Applicant’s arguments, with respect to the rejection of claims 1-20 under 35 U.S.C. 101 have been fully considered and are not persuasive. The rejections of claims 1-20 under 35 U.S.C. 101 have been maintained accordingly.
Applicant specifically argues that
1) “While certain dependent claims may relate to "an insurance underwriting process," for example, there is no limitation of the pending claims that actually recites any aspect of "insurance" itself, nor of any "business relations." Although the present Specification may provide "insurance" as one example of the application of the claimed subject assessments, limitations from the Specification are not to be imported into the claims. Moreover, providing an example of "insurance" as a use case does not suggest that any claim limitations actually recite "insurance." At least these claim limitations, as well as the limitations added with the present Amendment, do not recite certain methods of organizing human activity..”
Examiner respectfully disagrees with Applicant’s first argument.
During patent examination, the pending claims must be “given their broadest reasonable interpretation consistent with the specification.” The “directed to” inquiry applies a stage-one filter to claims, considered in light of the specification, based on whether their character as a whole is directed to excluded subject matter. Here, the specification provides evidence that the focus of the claims is not on a specific improvement in computer technology, but rather a process for calculating and updating a subject rating (i.e., vehicle grade, driver risk value, driver grade), because the subject rating is used/useful for “selling, purchasing, leasing, or insuring an object” (published disclosure at [0003]) and/or “encouraging good behavior” (published disclosure at [0004]) and/or “insurance underwriting” (published disclosure at [0102]). Applicant’s specification stats that the subject rating may be synonymous with a “risk score” that “may facilitate…insuring users or their objects/property” (published disclosure at [0049]-[0050]). As such, when considered as a whole, under the broadest reasonable interpretation in light of the Specification, the claims recite a process for generating a risk score associated with a vehicle/driver that can be used for insurance underwriting and/or mitigating risk and/or for valuing a vehicle for sale, which falls within the enumerated “Certain methods of Organizing Human Activity” grouping of abstract ideas (a fundamental economic principle or practice (e.g., insurance, mitigating risk); a commercial or legal interactions (specifically, 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.
Applicant specifically argues that
2) “Moreover, at least the recitations of "execute at least one model... ", "generate a token...", and "re-execute the at least one model..." are not reasonably characterized as mental steps. These actions are well-understood to be processor-based functionality necessarily rooted in computing technology and do not have "manual" corollaries.”
Examiner respectfully disagrees with Applicant’s second argument.
Humans are capable of “executing and/or “re-executing…at least one model” (e.g., using a pen and paper to use an algorithm/formula to calculate one or more values using one or more input values), and generate a token (e.g., represent data using other data, cryptography existed long before computers). Examiner disagrees the high-level recitation of “execute at least one model” is well-understood to be processor-based functionality necessarily rooted in computing technology that does not have a "manual" corollary. That being said, even if the phrase “execute at least one model” were somehow determined to be something only a computer can do, the phrase (for example) “with the plurality of data…generate a subject rating for the subject and a recommendation of at least one recommended action that would improve the subject rating” is still a step a human being is capable of performing that is recited in the claims (i.e., one or more judgments, evaluations), and the high-level requirement to “execute at least one model” to perform this step would amount to a requirement to apply the abstract idea with a general-purpose computer.
Applicant specifically argues that
3) “Prong Two… Here, the claims recite a specific, ordered arrangement of interactivity between the claimed computer system and a subject…That is, the computer system provides data (the recommendation) to the subject; the subject performs actions that are reflected in data monitored by the computer system, including following the recommendation (or not); and the computer system takes responsive action when the subject's actions are sufficiently significant to cause a detectable change in the subject rating.”
Examiner respectfully disagrees with Applicant’s third argument.
The analysis under Prong two of Step 2A is concerned with the “additional” elements in the claims. The “subject” not perform any of the method steps (or functions of the system). The “subject” is therefore not an “additional” element of the claimed invention. Examiner notes that the “subject” may be a human being (e.g., see claim 6). Instead, the only “additional” element(s) is the claimed computer system (e.g., general-purpose computer) that is used to implement the steps/functions of the claimed invention. Applicant has not disputed the Examiner’s finding that the additional elements are recited at a high level of generality as generic computer components. The focus of the claim as a whole is directed to a result or effect that itself is the abstract idea.
Applicant specifically argues that
4) “Dependent Claim 2 recites even more interactivity, in that, when the subject rating is improved, the computer system assigns more tasks to the subject. As described in the present specification, the improved rating, reflecting improved driving behavior and tangibly improved road safety, encourages platforms (such as TNCs) to rely more on that subject.”
Examiner respectfully disagrees with Applicant’s fourth argument.
As discussed above with respect to Applicant’s third argument, the “subject” is not an “additional” element of the claimed invention. Increasing a number of tasks associated with the subject (e.g., when the updated subject rating is improved) is part of the abstract idea. The only “additional” element in Applicant’s invention here is the use of the computer system to implement this abstract idea.
Applicant specifically argues that
5) “Step 2B… In the instant application, the pending claims clearly recite more than well-understood, routine, or conventional activities. This conclusion is evidenced at least by the conclusion that the claims recite subject matter that is patentable over the known art, as explained below.”
Examiner respectfully disagrees with Applicant’s fifth argument.
Whether or not any of the steps/formulas themselves, or the abstract idea as whole, is/are novel or non-obviousness is not determinative of eligibility. See Diamond v. Diehr, 450 U.S. 175, 188-89, (1981 - the novelty of a process or its steps is not relevant to determining whether the claimed subject matter is patentable). Elec. Commc’n Techs., LLC v. ShoppersChoice.com, LLC, 958 F.3d 1178, 1183 (Fed. Cir. 2020 - “[E]ven taking as true that claim 11 is ‘unique,’ that alone is insufficient to confer patent eligibility [when] the purported uniqueness of claim 11... is itself abstract.”’); Solutran, Inc. v. Elavon, Inc., 931 F.3d 1161, 1169 (Fed. Cir. 2019 – “merely reciting an abstract idea by itself in a claim—even if the idea is novel and non-obvious—is not enough to save it from ineligibility’’). The analysis under Step 2B is concerned with the “additional” elements in the claims.
v Applicant’s arguments, with respect to the rejection of amended claims 1, 11, and 16 (as well as each of the dependent claims) under 35 U.S.C. §103 have been considered, but are not persuasive.
Applicant argues “Notably, neither of these references, alone or in combination, describes or even suggests monitoring, in real time, actions of a subject to determine whether a recommended action was performed, re-executing at least one model with the plurality of data and updated data based upon the actions of the subject and the at least one recommended action to generate an updated subject rating, and in response to detecting a change between the subject rating and the updated subject rating, generating an updated NFT including a hash of the HFT and one or more of: the updated data or the updated subject rating. Rather, Kyne merely describes using a block chain to store information related to a trigger event (e.g., a traffic accident) or periodic data reports, or accessing a block chain to provide information to a driver. None of these actions are described as being responsive to a detected change in subject rating. Friesen merely describes minting NFTs in response to instructions”.
Examiner respectfully disagrees. Applicant’s argument that “neither of these references, alone or in combination, describes or even suggests monitoring, in real time, actions of a subject to determine whether a recommended action was performed, re-executing at least one model with the plurality of data and updated data based upon the actions of the subject and the at least one recommended action to generate an updated subject rating” is entirely conclusory, and is therefore not persuasive. Furthermore, Applicant has not addressed any of the citations or explanations provided by the Examiner in the previous Office Action demonstrating how and why these limitations are taught by the cited prior art.
Kyne clearly discloses monitoring, in real time, actions of a subject to determine whether a recommended action was performed (3:56-67 & 4:1-33 “embodiments may provide feedback to the driver (e.g., in real-time) in response to the sensor information and/or contextual information, which may encourage the driver to operate the vehicle within desirable parameters…the driver is notified each time the driver's vehicle operation results in adjusting the driver's insurance premium. Accordingly, the driver may be encouraged to minimize behaviors that result in an increase in the insurance premium and maximize behaviors that result in a decrease in the insurance premium. Supply of such data in real-time (e.g., within a matter of seconds from measurement) may facilitate a game-type display of data that encourages drivers to drive within certain performance boundaries to achieve a desired score….Such feedback may be facilitated by onboard analysis of data and computation of scores by a specially-programmed processor….in some embodiments, the driver is notified when the geographical location of the vehicle is considered high crime, traffic, or accident rate area…a route to exit such areas may be provided by the systems…driver may be proactively notified…and alternate routes to avoid such locations may be proactively offered. If the driver consistently avoids the high crime, traffic, or accident rate geographical location over time, then the driver may be rewarded by adjusting (reducing) the driver’s insurance premium…” – the system therefore continuously monitors the driving behavior of the subject in real time based on the sensor/contextual data that is continually collected (i.e., monitors actions of the subject) including to determine whether or not they followed a recommended action (e.g., a recommendation to avoid the high crime, traffic, or accident rate geographical location) to determine if the at least one recommended action was performed, see also 13:64-67 “real-time or essentially real-time updates…may be provided to the driver based on monitoring operational data and/or contextual information” and 15:33-67 & 16:1-4 “computing device 42 may run the software program via the processor to generate the risk factor…(e.g., in the monitoring device 12)…the risk factor may be generated and sent by the monitoring device 12 to the computing device 42 to update the driver of a result of the operation of the vehicle…the monitoring device 12 may enable the driver of the vehicle 10 to view how the driver's vehicle operation affects the driver's insurance premium. In particular, the monitoring device 12 may be configured to communicate to the driver that the driver's vehicle operation has resulted in an increasing, decreasing, or unchanged insurance premium. This may be done via communication of the vehicle information 40, which may include a score such as the risk factor” – the system monitors in real time actions of a subject to determine the user’s driving behavior (e.g., whether a recommended action was performed), 17:45-65 “driver may adjust vehicle operation…maximize behaviors that result in decreasing the driver’s insurance premium…driving at or below a posted speed limit...may offer alternate routes to avoid the high crime geographical locations. If the driver consistently avoids the high crime geographical location over time…reducing) the drivers insurance premium” – therefore actions are monitored to determine if the recommendation was followed, 12:4-7 “The block chain may also be used to provide real-time feedback to the driver”)
Kyne clearly discloses re-executing at least one model with the plurality of data and updated data based upon the actions of the subject and the at least one recommended action to generate an updated subject rating (4:1-33 “embodiments may provide feedback to the driver (e.g., in real-time) in response to the sensor information and/or contextual information, which may encourage the driver to operate the vehicle within desirable parameters…the driver is notified each time the driver's vehicle operation results in adjusting the driver's insurance premium. Accordingly, the driver may be encouraged to minimize behaviors that result in an increase in the insurance premium and maximize behaviors that result in a decrease in the insurance premium. Supply of such data in real-time (e.g., within a matter of seconds from measurement) may facilitate a game-type display of data that encourages drivers to drive within certain performance boundaries to achieve a desired score….Such feedback may be facilitated by onboard analysis of data and computation of scores by a specially-programmed processor….in some embodiments, the driver is notified when the geographical location of the vehicle is considered high crime, traffic, or accident rate area…a route to exit such areas may be provided by the systems…driver may be proactively notified…and alternate routes to avoid such locations may be proactively offered. If the driver consistently avoids the high crime, traffic, or accident rate geographical location over time, then the driver may be rewarded by adjusting (reducing) the driver’s insurance premium…” – the system iteratively re-executes the risk factor/value scoring to generate an updated risk factor/score for the driver (i.e., generate an updated subject rating) and subsequent/associated insurance premium calculation (per 3:22-24 & 5:39-42 & 13:14-21 premium is based on risk factor/score and therefore risk factor/score is updated/reduced as well if insurance premium is updated/reduced) based on the user’s updated historical driving/sensor data and the at least one recommended action to avoid the high risk areas (e.g., the previous data collected and any updated driving/sensor data based upon the actions of the subject and the at least one recommended action), 9:47-63 “calculated risk value or some other value based on the various pieces of information…calculate a risk value…data received by the monitoring device may be processed…to provide a potential change in…a related score…for viewing by the driver…to encourage a change in driving behavior” – scoring model(s) are iteratively re-executed to generate updated ratings/scores, 15:15-18 “the risk factor may be based at least in part on the historical information related to the vehicle and/or the driver” (historical and updated information used to iteratively calculate risk factor), 15:33-67 & 16:1-4 “computing device 42 may run the software program via the processor to generate the risk factor…(e.g., in the monitoring device 12)…the risk factor may be generated and sent by the monitoring device 12 to the computing device 42 to update the driver of a result of the operation of the vehicle…the monitoring device 12 may enable the driver of the vehicle 10 to view how the driver's vehicle operation affects the driver's insurance premium. In particular, the monitoring device 12 may be configured to communicate to the driver that the driver's vehicle operation has resulted in an increasing, decreasing, or unchanged insurance premium. This may be done via communication of the vehicle information 40, which may include a score such as the risk factor”, 13:3-48 “the score is represented by a risk factor…indicating a higher risk associated with the driver…may be represented numerically…risk factor may be the basis for the insurer or the algorithm to determine and/or adjust the driver’s insurance premium…adjust the risk value based on the risk factor…difference between an original score and a current score… lower risk factor may result in a decrease of the driver's insurance premium”).
Examiner disagrees that the combination of Kyne and Friesen fail to teach or suggest the limitation “in response to detecting a change between the subject rating and the updated subject rating, generating an updated NFT including a hash of the HFT and one or more of: the updated data or the updated subject rating.” As acknowledged by Applicant, Kyne discloses storing data used by the system on a blockchain such as data associated with the subject and other information used to provide information to driver (4:40-53 “may employ various systems and techniques for handling data to improve efficiency associated with transferring information, maintenance of privacy, confirmation of trusted data sources, conservation of data storage…For example, present embodiments may employ a block chain distributed database as a repository of vehicle operation and/or contextual information (as data records in the block chain)…which may facilitate organized storage and prevent illicit tampering or revision to the data. Further, the block chain repository may establish the vehicle operation and/or contextual information as immutable and trusted…” – therefore the system generates one or more immutable data elements including at least the sensor/contextual data (i.e., non-fungible data elements including the plurality of data), 9:51-58 & 10:7-9 “processor may be configured to select certain data from the vehicle information and…generate/update a block chain…”…“vehicle information…may refer to any portion and/or form of the sensor information as received from the sensors of the vehicle…including modifications to the vehicle information, such as…calculating a score as the vehicle information” – therefore the plurality of data (the sensor data) and/or the calculated scores (subject rating(s) may be written to the block chain). Kyne also discloses updating/storing a hash of the non-fungible block, (9:51-58 & 10:7-9 “processor may be configured to select certain data from the vehicle information and…generate/update a block chain) such that it is ready for transfer to the computing device 42 for additional processing”…“vehicle information…may refer to any portion and/or form of the sensor information as received from the sensors of the vehicle…including modifications to the vehicle information, such as…calculating a score as the vehicle information” – therefore the plurality of data (the sensor data) and/or the calculated scores (subject rating(s) may be written to the block chain to generate an updated block (which necessarily comprises a hash of the blockchain block/data as is an inherent part of storing/updating information in a blockchain – Which Applicant has failed to shown/argue is not the case). As discussed above, Kyne clearly discloses monitoring actions of the subject in real time and real-time updating of information (e.g., newly received sensor/driving data associated with a subject, the subject rating, etc.) and further providing this updated information (e.g., an updated score/rating) to the subject in real time or near real time. Therefore, the blockchain is updated in response to any new and/or updated/changed information (e.g., including a detected change in a subject rating). Updating a stored current subject rating on the blockchain (e.g. from a first score to a second score) amounts to generating an updated non-fungible block or data element on the blockchain in response to detecting a change between the subject rating and the updated subject rating, consistent with Applicant’s own disclosure (see, for example, [0040]-[0044] & [0091]-[0092] & [0143]-[0145] which generally discusses updating and/or overwriting data based on new or updated/different information). There is no suggestion or requirement that the blockchain (NFT) is updated only in response to a detected change. However, Kyne further discloses updating a “delta” value, which is a score/value that represents “a difference between in original score and a current score” that “may demonstrate improvement or decline in driver rating…” and the “delta score may be generated based on how the score changes over time” and “may be presented via a user interface…to encourage changes to driving habits” (see 13:21-41). This delta score is similarity stored as a non-fungible block or data element on the blockchain, and is updated in response to detecting a change between the subject rating and the updated subject rating. As such, Kyne discloses another instance of “in response to detecting a change between the subject rating and the updated subject rating, generating an updated non-fungible block or data element on the blockchain including a hash of the non-fungible block or data element and one or more of: the updated data or the updated subject rating.”.
As discussed previously, the only thing not taught by Kyne is generating an NFT on a blockchain including some or all of this information. As discussed previously, Friesen discloses generating a non-fungible token (NFT) including this type of information. As such, the combination of Kyne (which teaches in response to detecting a change between the subject rating and the updated subject rating, generating an updated non-fungible block or data element on the blockchain including a hash of the non-fungible block or data element and one or more of: the updated data or the updated subject rating) and Friesen (which discloses wherein NFTs may be generated to comprise/represent non-fungible blocks or data elements on the blockchain ) disclose the recited limitation.
Claim Objections
Claims 1, 11, and 16 are objected to because of the following informalities: --NFT-- should be inserted to replace “HFT” in the “in response to detecting…generating an updated NFT including a has of the HFT…” limitation. This appears to be a typo. Appropriate correction is required.
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) 11-15 is/are drawn to methods (i.e., a process), claim(s) 1-10 is/are drawn to systems (i.e., a machine/manufacture), and claim(s) 16-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) 11 and 16) recites/describes the following steps;
receive a plurality of data associated with a history of a subject;
execute at least one model with the plurality of data to generate a subject rating for the subject and a recommendation of at least one recommended action that would improve the subject rating;
generate a token including one or more of: the plurality of data, the subject rating, or the recommendation;
output, to the subject, the recommendation
monitor, in real time, actions of the subject to determine whether the at least one recommended action was performed;
re-execute the at least one model with the plurality of data and updated data based upon the actions of the subject and the at least one recommended action to generate an updated subject rating
in response to detecting a change between the subject rating and the updated subject rating, generate an updated token including a hash of the token and one or more of: the updated data or the updated subject rating
These steps, under its broadest reasonable interpretation, describe or set-forth a process for generating subject ratings, providing recommendations to a subject to improve the rating, and updating subject ratings based on tracked actions. More specifically, this process comprises generating a subject rating for a subject using a model and a plurality of received data associated with a history of the subject, generating a recommended action that would improve the subject rating, generating a token including one or more of the plurality of data, the rating, or the recommendation; monitoring actions to determine whether the recommended action was performed; re-executing the at least one model with the plurality of data and updated data based upon the actions of the subject and the at least one recommended action to generate an updated subject rating (e.g., a rating used for insurance underwriting), and generating an updated token and token hash including the updated subject rating (when changed). During patent examination, the pending claims must be “given their broadest reasonable interpretation consistent with the specification.” Here, the specification provides evidence that a subject rating may be vehicle grade, driver risk value, driver grade, and that the subject rating is used/useful for “selling, purchasing, leasing, or insuring an object” (published disclosure at [0003]) and/or “encouraging good behavior” (published disclosure at [0004]) and/or “insurance underwriting” (published disclosure at [0102]). Applicant’s specification stats that the subject rating may be synonymous with a “risk score” that “may facilitate…insuring users or their objects/property” (published disclosure at [0049]-[0050]). As such, the process amounts to a fundamental economic principle or practice (e.g., insurance, mitigating risk); a commercial or legal interactions (specifically, 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.
Additionally, and/or alternatively, each of the above-recited steps/functions, under their broadest reasonable interpretation, encompass a human manually (e.g., in their mind, or using paper and pen) performing one or more concepts performed in the human mind, such as one or more observations, evaluations, judgments, opinions, but for the recitation of generic computer components. If one or more claim limitations, under their broadest reasonable interpretation, covers performance of the limitation(s) in the mind but for the recitation of generic computer components, then it falls within the “mental processes” 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) 11 and 16 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. The same reasoning is similarly applicable to the limitations in the remaining dependent claims, and their respective limitations are not reproduced here for the sake of brevity.
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
“a computer system including at least one processor in communication with at least one memory device, the at least one processor programmed to” (claim 1);
“computer-implemented…implemented using a token management (TM) computing device including at least one processor in communication with at least one memory” (claim 11);
“at least one non-transitory computer-readable storage medium storing thereon computer-executable instructions that, when executed by at least one processor, cause the at least one processor to” (claim 16)
“generate a non-fungible token (NFT) including one or more of…updated NFT…hash of the NFT…” (claims 1, 11, and 16)
“wherein the at least one processor is further programmed to” (claims 4, 6, and 10)
“wherein the computer-executable instructions further cause the processor to” (claim 18)
“receive data associated with the actions from a third-party server associated with the on-demand platform” (claims 4, 13, and 18)
“receive the plurality of data in real-time during usage operation of a vehicle, the plurality of data corresponding to one or more driving behaviors of the driver” (claims 10 and 15)
The requirement to execute the claimed steps/functions using “a computer system including at least one processor in communication with at least one memory device, the at least one processor programmed to” (claim 1), the recitation of “computer-implemented…implemented using a token management (TM) computing device including at least one processor in communication with at least one memory” (claim 11), the recitation of “at least one non-transitory computer-readable storage medium storing thereon computer-executable instructions that, when executed by at least one processor, cause the at least one processor to” (claim 16), the recitation of “wherein the at least one processor is further programmed to” (claims 4, 6, and 10), and the recitation of “wherein the computer-executable instructions further cause the processor to” (claim 18) 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 disclosure explains that these “additional” elements may be embodied as a general-purpose computer (e.g., the published specification at paragraph [0118] “System 200 includes a token management (TM) computing device 202, also referred to as a TM server, which may perform one or more steps of processes 100 and 600. In the exemplary embodiment, TM computing device 202 includes one or more computers that include a web browser or a software application, which enables TM computing device(s) 202 to receive data and messages from other devices over a network 204 using the Internet”, paragraph [0123] “computing devices 210 are computers that include a web browser or a software application, which enables client computing devices 210 to access TM computing device 202 via network 204 using the Internet. Client computing device 210 may be any device capable of accessing the Internet including, but not limited to, a mobile device, a desktop computer, a laptop computer, a personal digital assistant (PDA), a cellular phone, a smartphone, a tablet, a phablet…”, and paragraphs [0157]-[0161]). 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 “generate a non-fungible token (NFT) including one or more of…updated NFT…hash of the NFT…”” (claims 1, 11, and 16), and “from a third-party server associated with the on-demand platform” (claims 4, 13, and 18) 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 (e.g., digital asset file/information/token stored in a digital ledger), exchanged between computers over a network, and presented using graphical user interfaces. 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 elements of “receive a plurality of data associated with a history of a subject” (claims 1, 11, and 16) and “wherein the plurality of data includes historical reference data associated with the subject and sensor data captured by one or more sensors associated with the subject” (claim 3) and “wherein the plurality of data includes sensor data received from sensors disposed within at least one of a user computing device or a vehicle operated by the subject” (claim 8), even if considered to be an “additional” element for the purpose of the eligibility analysis, as well as the additional element(s) of “receive data associated with the actions from a third-party server associated with the on-demand platform” (claims 4, 13, and 18) and “receive the plurality of data in real-time during usage operation of a vehicle, the plurality of data corresponding to one or more driving behaviors of the driver” (claims 10 and 15), 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 all uses of the recited judicial exceptions require such data gathering, and because such data gathering have long been held to be insignificant pre/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) and (g)).
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 an accurate and up-to-date history of an object (e.g., vehicle, driver risk, driver grade, etc.) as well as subject ratings of the object is advantageous for parties who need to make business decisions using this information (e.g., buying/trading the object, underwriting the driver, etc.) (see, for example, Applicant’s published disclosure at paragraphs [0003]-[0004] & [0037]-[0039] & [0050] & [0077]). 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 updating/calculating a subject rating and motivating behavioral change).
Dependent claims 2, 3, 5, 7-9, 12, 14, 17, 19, and 20 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims 2, 3, 5, 7-9, 12, 14, 17, 19, 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 5 recites “wherein the plurality of data includes evaluation criteria of the subject from the on-demand platform”. This is an abstract limitation which further sets forth the abstract idea encompassed by claim 5 (it describes the data being received/analyzed). 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 using “a computer system including at least one processor in communication with at least one memory device, the at least one processor programmed to” (claim 1), the recitation of “computer-implemented…implemented using a token management (TM) computing device including at least one processor in communication with at least one memory” (claim 11), the recitation of “at least one non-transitory computer-readable storage medium storing thereon computer-executable instructions that, when executed by at least one processor, cause the at least one processor to” (claim 16), the recitation of “wherein the at least one processor is further programmed to” (claims 4, 6, and 10), and the recitation of “wherein the computer-executable instructions further cause the processor to” (claim 18) 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 “generate a non-fungible token (NFT) including one or more of…updated NFT…hash of the NFT…” (claims 1, 11, and 16), and “from a third-party server associated with the on-demand platform” (claims 4, 13, and 18) 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 elements of “receive a plurality of data associated with a history of a subject” (claims 1, 11, and 16) and “wherein the plurality of data includes historical reference data associated with the subject and sensor data captured by one or more sensors associated with the subject” (claim 3) and “wherein the plurality of data includes sensor data received from sensors disposed within at least one of a user computing device or a vehicle operated by the subject” (claim 8), even if considered to be an “additional” element for the purpose of the eligibility analysis, as well as the additional element(s) of “receive data associated with the actions from a third-party server associated with the on-demand platform” (claims 4, 13, and 18) and “receive the plurality of data in real-time during usage operation of a vehicle, the plurality of data corresponding to one or more driving behaviors of the driver” (claims 10 and 15), 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). These additional element(s), taken individually or in combination, 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 insurance underwriting. 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. 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, generally link the abstract idea to a particular technological environment or field of use, 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, 3, 5, 7-9, 12, 14, 17, 19, and 20 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims 2, 3, 5, 7-9, 12, 14, 17, 19, 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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2, 12, and 17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
v Claims 2, 12, and 17 recite “when the updated subject rating is improved relative to the subject rating, indicating the actions of the subject reflect that the subject performed the at least one recommended action, increase a number of tasks associated with the subject” and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. This language contains multiple grammatical and/or syntax errors, and the meaning of this phrase (and therefore the scope of the invention) is unclear. Therefore, the claim is indefinite for failing to particularly and distinctly claim the subject matter which the application regards as the invention. For the purpose of examination, the phrase “when the updated subject rating is improved relative to the subject rating, indicating the actions of the subject reflect that the subject performed the at least one recommended action, increase a number of tasks associated with the subject” will be interpreted as being “when the updated subject rating is improved relative to the subject rating, indicating that the actions of the subject reflect that the subject performed the at least one recommended action[[,]] or increase a number of tasks associated with the subject.”
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
v Claims 1-3, 6-12, 14-17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kyne et al. (U.S. Patent No. 10,726,493 July 28, 2020 - hereinafter "Kyne”) in view of Friesen et al. (U.S. PG Pub No. 2025/0156506, May 15, 2025 - hereinafter "Friesen”)
With respect to claims 1, 11, and 16, Kyne teaches a computer system for autonomously generating and maintaining real-time tokenized subject assessments including at least one processor in communication with at least one memory device (claim 1) (6:62-65 “monitoring device may include a memory”, 9:50-51 “monitoring device may include one or more processors”, 10:17-18 “may include a server, computer…”, 16:37-39 “the computing device 42 or the monitoring device 12 may include a software program stored in the memory that is configured to generate the risk factor”) a computer-implemented method for autonomously generating and maintaining real-time tokenized subject assessments implemented using a token management (TM) computing device including at least one processor in communication with at least one memory (claim 11) (6:62-65 “monitoring device may include a memory”, 9:50-51 “monitoring device may include one or more processors” , 10:17-18 “may include a server, computer…”) and at least one non-transitory computer-readable storage medium storing thereon computer-executable instructions that, when executed by at least one processor, cause the at least one processor to (claim 16) (6:62-65 “monitoring device may include a memory”, 9:50-51 “monitoring device may include one or more processors”, 10:17-18 “may include a server, computer…”) ;
receive a plurality of data associated with a history of a subject; (2:33-59 “tracking operation of a vehicle (e.g., automobile, truck, motorcycle, RV, boat, airplane, snowmobile) and/or actions of a driver of the vehicle…incentivizing the driver to operate the vehicle in a safe manner…Sensor information related to the operation of the vehicle may be provided from sensors integral with systems of the vehicle, coupled with the vehicle, and/or disposed in or around the vehicle (e.g., a smart phone within the vehicle). Contextual information (i.e., information related to a context or a vehicle context of the sensor information) may also be acquired from sensors associated with (e.g., integral with or disposed in) the vehicle or from external data sources (e.g., other vehicles). Contextual information relating to the actions of the driver…weather-related conditions… can be captured by certain onboard sensors” – therefore vehicle sensor/telematic data associated with a driver (i.e., “data associated with a history of a subject”) is received (i.e., the system receives this data), 5:8-16 “The monitoring system 11 may monitor the vehicle 10 via an interface with the vehicle 10 or as an integral part of the vehicle 10. In some embodiments, the system 11 includes a monitoring device 12, which may include integral sensors and/or couple to the vehicle 10 such that the monitoring device 12 may access sensor information provided from one or more separate sensors, such as sensors 16, 18, of the vehicle 10”, 7:11-46 “monitoring device 12 may receive the sensor information provided from the sensors…oxygen sensor…wheel speed sensor…any sensors of the vehicle…weather detection sensor, a temperature sensor…information relating to speed of the vehicle…”)
execute at least one model with the plurality of data to generate a subject rating for the subject; (3:16-24 “The sensor information and/or the contextual information may be analyzed such that a risk factor or other score may be generated…knowledge of wet road conditions on which the driver operated the vehicle at an excessive speed may serve to increase a risk factor of the actions of the driver…” – the system generates a risk factor or score associated with the actions of the driver (i.e., a subject rating for the subject) based on the sensor and contextual data (i.e., the plurality of data), 5:35-47 “factor based on statistical analysis, models, comparisons, or other evaluations… calculations (based on sensor data) to define factors or scores used in insurance adjustment …risk assessment based on driving data” – at least one model is executed with the sensors data to generate at least one risk/driving score/factor/assessment for the driver (i.e., subject rating for the subject), 9:47-63 “calculated risk value or some other value based on the various pieces of information…calculate a risk value…data received by the monitoring device may be processed…to provide a potential change in…a related score…for viewing by the driver…to encourage a change in driving behavior”, 13:3-41 “the score is represented by a risk factor…indicating a higher risk associated with the driver…may be represented numerically…risk factor may be the basis for the insurer or the algorithm to determine and/or adjust the driver’s insurance premium…adjust the risk value based on the risk factor…difference between an original score and a current score”, 16:19-24 “algorithm…generate…risk factor…”)
and a recommendation of at least one recommended action that would improve the subject rating (4:14-33 “in some embodiments, the driver is notified when the geographical location of the vehicle is considered high crime, traffic, or accident rate area…a route to exit such areas may be provided by the systems…driver may be proactively notified…and alternate routes to avoid such locations may be proactively offered. If the driver consistently avoids the high crime, traffic, or accident rate geographical location over time, then the driver may be rewarded by adjusting (reducing) the driver’s insurance premium…” – therefore the system generates a recommendation of at least a safer route (i.e., “at least one recommended action”) that would lower the driver’s risk factor/score and therefore their associated insurance premium (per 3:22-24 & 5:39-42 & 13:14-21 premium is based on calculated risk factor/scores) and this recommended action that would improve the subject rating is consistent with Applicant’s published disclosure at [0189], 11:15-21 recommending safer route alternatives and/or recommendation to move away from an unsafe vehicle, 17:45-65 “driver may adjust vehicle operation…maximize behaviors that result in decreasing the driver’s insurance premium…driving at or below a posted speed limit...consistently avoids the high crime geographical location over time…”)
generate a non-fungible data block or element including one or more of: the plurality of data, the subject rating, or the recommendation; (4:40-53 “may employ various systems and techniques for handling data to improve efficiency associated with transferring information, maintenance of privacy, confirmation of trusted data sources, conservation of data storage…For example, present embodiments may employ a block chain distributed database as a repository of vehicle operation and/or contextual information (as data records in the block chain)…which may facilitate organized storage and prevent illicit tampering or revision to the data. Further, the block chain repository may establish the vehicle operation and/or contextual information as immutable and trusted…” – therefore the system generates one or more immutable data elements including at least the sensor/contextual data (i.e., non-fungible data elements including the plurality of data), 9:51-58 & 10:7-9 “processor may be configured to select certain data from the vehicle information and…generate/update a block chain…”…“vehicle information…may refer to any portion and/or form of the sensor information as received from the sensors of the vehicle…including modifications to the vehicle information, such as…calculating a score as the vehicle information” – therefore the plurality of data (the sensor data) and/or the calculated scores (subject rating(s) may be written to the block chain)
output, to the subject, the recommendation (4:14-33 “embodiments may provide feedback to the driver (e.g., in real-time) in response to the sensor information and/or contextual information, which may encourage the driver to operate the vehicle within desirable parameters….in some embodiments, the driver is notified when the geographical location of the vehicle is considered high crime, traffic, or accident rate area…a route to exit such areas may be provided by the systems…driver may be proactively notified…and alternate routes to avoid such locations may be proactively offered. If the driver consistently avoids the high crime, traffic, or accident rate geographical location over time, then the driver may be rewarded by adjusting (reducing) the driver’s insurance premium…” …” – therefore the recommendation of at least a safer route (i.e., “at least one recommended action”) is output to the subject, 11:15-21 recommending safer route alternatives and/or recommendation to move away from an unsafe vehicle)
monitoring, in real time, actions of a subject to determine whether a recommended action was performed (3:56-67 & 4:1-33 “embodiments may provide feedback to the driver (e.g., in real-time) in response to the sensor information and/or contextual information, which may encourage the driver to operate the vehicle within desirable parameters…the driver is notified each time the driver's vehicle operation results in adjusting the driver's insurance premium. Accordingly, the driver may be encouraged to minimize behaviors that result in an increase in the insurance premium and maximize behaviors that result in a decrease in the insurance premium. Supply of such data in real-time (e.g., within a matter of seconds from measurement) may facilitate a game-type display of data that encourages drivers to drive within certain performance boundaries to achieve a desired score….Such feedback may be facilitated by onboard analysis of data and computation of scores by a specially-programmed processor….in some embodiments, the driver is notified when the geographical location of the vehicle is considered high crime, traffic, or accident rate area…a route to exit such areas may be provided by the systems…driver may be proactively notified…and alternate routes to avoid such locations may be proactively offered. If the driver consistently avoids the high crime, traffic, or accident rate geographical location over time, then the driver may be rewarded by adjusting (reducing) the driver’s insurance premium…” – the system therefore continuously monitors the driving behavior of the subject in real time based on the sensor/contextual data that is continually collected (i.e., monitors actions of the subject) including to determine whether or not they followed a recommended action (e.g., a recommendation to avoid the high crime, traffic, or accident rate geographical location) to determine if the at least one recommended action was performed, see also 13:64-67 “real-time or essentially real-time updates…may be provided to the driver based on monitoring operational data and/or contextual information” and 15:33-67 & 16:1-4 “computing device 42 may run the software program via the processor to generate the risk factor…(e.g., in the monitoring device 12)…the risk factor may be generated and sent by the monitoring device 12 to the computing device 42 to update the driver of a result of the operation of the vehicle…the monitoring device 12 may enable the driver of the vehicle 10 to view how the driver's vehicle operation affects the driver's insurance premium. In particular, the monitoring device 12 may be configured to communicate to the driver that the driver's vehicle operation has resulted in an increasing, decreasing, or unchanged insurance premium. This may be done via communication of the vehicle information 40, which may include a score such as the risk factor” – the system monitors in real time actions of a subject to determine the user’s driving behavior (e.g., whether a recommended action was performed), 17:45-65 “driver may adjust vehicle operation…maximize behaviors that result in decreasing the driver’s insurance premium…driving at or below a posted speed limit...may offer alternate routes to avoid the high crime geographical locations. If the driver consistently avoids the high crime geographical location over time…reducing) the drivers insurance premium” – therefore actions are monitored to determine if the recommendation was followed, 12:4-7 “The block chain may also be used to provide real-time feedback to the driver”)
re-execute the at least one model with the plurality of data and updated data based upon the actions of the subject and the at least one recommended action to generate an updated subject rating (4:1-33 “embodiments may provide feedback to the driver (e.g., in real-time) in response to the sensor information and/or contextual information, which may encourage the driver to operate the vehicle within desirable parameters…the driver is notified each time the driver's vehicle operation results in adjusting the driver's insurance premium. Accordingly, the driver may be encouraged to minimize behaviors that result in an increase in the insurance premium and maximize behaviors that result in a decrease in the insurance premium. Supply of such data in real-time (e.g., within a matter of seconds from measurement) may facilitate a game-type display of data that encourages drivers to drive within certain performance boundaries to achieve a desired score….Such feedback may be facilitated by onboard analysis of data and computation of scores by a specially-programmed processor….in some embodiments, the driver is notified when the geographical location of the vehicle is considered high crime, traffic, or accident rate area…a route to exit such areas may be provided by the systems…driver may be proactively notified…and alternate routes to avoid such locations may be proactively offered. If the driver consistently avoids the high crime, traffic, or accident rate geographical location over time, then the driver may be rewarded by adjusting (reducing) the driver’s insurance premium…” – the system iteratively re-executes the risk factor/value scoring to generate an updated risk factor/score for the driver (i.e., generate an updated subject rating) and subsequent/associated insurance premium calculation (per 3:22-24 & 5:39-42 & 13:14-21 premium is based on risk factor/score and therefore risk factor/score is updated/reduced as well if insurance premium is updated/reduced) based on the user’s updated historical driving/sensor data and the at least one recommended action to avoid the high risk areas (e.g., the previous data collected and any updated driving/sensor data based upon the actions of the subject and the at least one recommended action), 9:47-63 “calculated risk value or some other value based on the various pieces of information…calculate a risk value…data received by the monitoring device may be processed…to provide a potential change in…a related score…for viewing by the driver…to encourage a change in driving behavior” – scoring model(s) are iteratively re-executed to generate updated ratings/scores, 15:15-18 “the risk factor may be based at least in part on the historical information related to the vehicle and/or the driver” (historical and updated information used to iteratively calculate risk factor), 15:33-67 & 16:1-4 “computing device 42 may run the software program via the processor to generate the risk factor…(e.g., in the monitoring device 12)…the risk factor may be generated and sent by the monitoring device 12 to the computing device 42 to update the driver of a result of the operation of the vehicle…the monitoring device 12 may enable the driver of the vehicle 10 to view how the driver's vehicle operation affects the driver's insurance premium. In particular, the monitoring device 12 may be configured to communicate to the driver that the driver's vehicle operation has resulted in an increasing, decreasing, or unchanged insurance premium. This may be done via communication of the vehicle information 40, which may include a score such as the risk factor”, 13:3-48 “the score is represented by a risk factor…indicating a higher risk associated with the driver…may be represented numerically…risk factor may be the basis for the insurer or the algorithm to determine and/or adjust the driver’s insurance premium…adjust the risk value based on the risk factor…difference between an original score and a current score… lower risk factor may result in a decrease of the driver's insurance premium”)
in response to detecting a change between the subject rating and the updated subject rating, generating an updated non-fungible block or data element on the blockchain including a hash of the non-fungible block or data element and one or more of: the updated data or the updated subject rating (9:51-58 & 10:7-9 “processor may be configured to select certain data from the vehicle information and…generate/update a block chain) such that it is ready for transfer to the computing device 42 for additional processing”…“vehicle information…may refer to any portion and/or form of the sensor information as received from the sensors of the vehicle…including modifications to the vehicle information, such as…calculating a score as the vehicle information” – therefore the plurality of data (the sensor data) and/or the calculated scores (subject rating(s) may be written to the block chain to generate an updated block (which necessarily comprises a hash of the blockchain block/data as is an inherent part of storing/updating information in a blockchain - As discussed above, Kyne clearly discloses monitoring actions of the subject in real time and real-time updating of information (e.g., newly received sensor/driving data associated with a subject, the subject rating, etc.) and further providing this updated information (e.g., an updated score/rating) to the subject in real time or near real time. Therefore, because the blockchain stores this information as blocks, the blockchain is updated in response to any new and/or updated/changed information (e.g., including a detected change in a subject rating). Updating a stored current subject rating on the blockchain (e.g. from a first score to a second score) amounts to generating an updated non-fungible block or data element on the blockchain in response to detecting a change between the subject rating and the updated subject rating, consistent with Applicant’s own disclosure (see, for example, [0040]-[0044] & [0091]-[0092] & [0143]-[0145] which generally discusses updating and/or overwriting data based on new or updated/different information). There is no suggestion or requirement that the blockchain (NFT) is updated only in response to a detected change. However, Kyne further discloses updating a “delta” value, which is a score/value that represents “a difference between in original score and a current score” that “may demonstrate improvement or decline in driver rating…” and the “delta score may be generated based on how the score changes over time” and “may be presented via a user interface…to encourage changes to driving habits” (see 13:21-41). This delta score is similarity stored as a non-fungible block or data element on the blockchain, and is updated in response to detecting a change between the subject rating and the updated subject rating”.
Although Kyne discloses storing various pieces information associated with the subject (e.g., data associated with the history of the subject, subject rating, etc.) as one or more blocks on a blockchain (therefore generating a non-fungible block or data element), Kyne does not appear to specifically disclose generating an NFT including some or all of this information. Kyne does not appear to disclose,
wherein the one or more non-fungible blocks or data elements on the blockchain are a non-fungible token (NFT) (e.g., an NFT including one or more of: the plurality of data, the subject rating, or the recommendation)
However, Friesen discloses
one or more non-fungible blocks or data elements on the blockchain are a generated non-fungible token (NFT) (e.g., an NFT including one or more of: the plurality of data, the subject rating, or the recommendation) ([0009]-[0013] “system mints at least one NFT assigned to a vehicle, the NFT comprising at least a proof of ownership, usage rights, and/or properties of the vehicle, wherein at least one vehicle-internal recording device records vehicle-related raw data, a vehicle-internal, and/or a vehicle-external collection device stores at least a sub-set of the raw data, and wherein at least a sub-set of stored raw data is prepared, prepared data is converted into NFT input data, and an NFT is minted incorporating the NFT input data…NFTs can be minted for vehicles, the NFTs can be enriched with information relevant to the respective vehicles and can be assigned to the corresponding vehicles, or to a corresponding vehicle user…Vehicle-related raw data is recorded using the vehicle-internal recording device. The recording device can be a sensor, and the raw data can be measured values of the respective sensor…” – therefore the system generates an NFT including at least sensor data associated with a history of a subject (e.g., the vehicle itself or a user/driver of the vehicle), [0081] “non-fungible tokens NFT to be generated according to the NFT input data ED are finally minted by the minting device PRÄ by including corresponding information blocks in the respective underlying blockchain” – NFT minted comprising the data from the information blocks , [0057] “By minting such NFTs, the state of the vehicle can also be evaluated…the number of kickdowns carried out can be counted, and for example an NFT”, [0078] “ data telling the respective vehicles 2 which raw data RD needs to be collected to generate the corresponding non-fungible tokens NFT and how the data should be further processed”)
Friesen suggests it is advantageous to include wherein the one or more non-fungible blocks or data elements on the blockchain are a non-fungible token (NFT) (e.g., an NFT including one or more of: the plurality of data, the subject rating, or the recommendation), because use of NFTs to document vehicle-related data (or data in general) allows a particularly flexible design of a subsequent use of the information stored in the blockchain (as an NFT) ([0009] & [0017]).
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 system, method, and medium of Kyne to include wherein the one or more non-fungible blocks or data elements on the blockchain are a non-fungible token (NFT) (e.g., an NFT including one or more of: the plurality of data, the subject rating, or the recommendation), as taught by Friesen, because use of NFTs to document vehicle-related data (or data in general) allows a particularly flexible design of a subsequent use of the information stored in the blockchain (as an NFT). Examiner notes that modification of Kynes method/system to use NFTs as opposed to simply non-fungible data blocks/elements would similarly result in updating of the NFT (as opposed to updating the non-fungible block or data element on the blockchain).
Furthermore, as in Friesen, it was within the capabilities of one of ordinary skill in the art to modify the system, method, and medium of Kyne to include wherein the one or more non-fungible blocks or data elements on the blockchain are a non-fungible token (NFT) (e.g., an NFT including one or more of: the plurality of data, the subject rating, or the recommendation). Furthermore, as in Friesen, the results of doing so would have been predictable to one of ordinary skill in the art. It would have been predictable to one of ordinary skill in the art that doing so would allow a particularly flexible design of a subsequent use of the information stored in the blockchain, as is needed in Kyne.
With respect to claims 2, 12, and 17, Kyne teaches the system of claim 1, the method of claim 11, and the medium of claim 16;
when the updated subject rating is improved relative to the subject rating, indicating that the actions of the subject reflect that the subject performed the at least one recommended action[[,]] or increase a number of tasks associated with the subject (4:1-33 “embodiments may provide feedback to the driver (e.g., in real-time) in response to the sensor information and/or contextual information, which may encourage the driver to operate the vehicle within desirable parameters…the driver is notified each time the driver's vehicle operation results in adjusting the driver's insurance premium. Accordingly, the driver may be encouraged to minimize behaviors that result in an increase in the insurance premium and maximize behaviors that result in a decrease in the insurance premium. Supply of such data in real-time (e.g., within a matter of seconds from measurement) may facilitate a game-type display of data that encourages drivers to drive within certain performance boundaries to achieve a desired score….Such feedback may be facilitated by onboard analysis of data and computation of scores by a specially-programmed processor….in some embodiments, the driver is notified when the geographical location of the vehicle is considered high crime, traffic, or accident rate area…a route to exit such areas may be provided by the systems…driver may be proactively notified…and alternate routes to avoid such locations may be proactively offered. If the driver consistently avoids the high crime, traffic, or accident rate geographical location over time, then the driver may be rewarded by adjusting (reducing) the driver’s insurance premium…” – the system iteratively re-executes the risk factor/value scoring to generate an updated risk factor/score for the driver (i.e., generate an updated subject rating) which “indicates” that the actions of the subject reflect that the subject performed the at least one recommended action, 9:47-63 “calculated risk value or some other value based on the various pieces of information…calculate a risk value…data received by the monitoring device may be processed…to provide a potential change in…a related score…for viewing by the driver…to encourage a change in driving behavior” – scoring model(s) are iteratively re-executed to generate updated ratings/scores, 15:15-18 “the risk factor may be based at least in part on the historical information related to the vehicle and/or the driver” (historical and updated information used to iteratively calculate risk factor), 15:33-67 & 16:1-4 “computing device 42 may run the software program via the processor to generate the risk factor…(e.g., in the monitoring device 12)…the risk factor may be generated and sent by the monitoring device 12 to the computing device 42 to update the driver of a result of the operation of the vehicle…the monitoring device 12 may enable the driver of the vehicle 10 to view how the driver's vehicle operation affects the driver's insurance premium. In particular, the monitoring device 12 may be configured to communicate to the driver that the driver's vehicle operation has resulted in an increasing, decreasing, or unchanged insurance premium. This may be done via communication of the vehicle information 40, which may include a score such as the risk factor”, 13:3-48 “the score is represented by a risk factor…indicating a higher risk associated with the driver…may be represented numerically…risk factor may be the basis for the insurer or the algorithm to determine and/or adjust the driver’s insurance premium…adjust the risk value based on the risk factor…difference between an original score and a current score… lower risk factor may result in a decrease of the driver's insurance premium”)
With respect to claim 3, Kyne teaches the system of claim 1;
wherein the plurality of data includes historical reference data associated with the subject (11:16-17 “the driver’s route history may be analyzed…”, 16:17-19 “risk factor may be based at least in part on the historical information related to the vehicle 10 and/or the driver”, 13:32-39 “difference between an original score and a current score…delta score may be generated…” – historical/old risk score associated with the driver is also historical reference data associated with the subject)
and sensor data captured by one or more sensors associated with the subject (2:33-59 “tracking operation of a vehicle (e.g., automobile, truck, motorcycle, RV, boat, airplane, snowmobile) and/or actions of a driver of the vehicle…incentivizing the driver to operate the vehicle in a safe manner…Sensor information related to the operation of the vehicle may be provided from sensors integral with systems of the vehicle, coupled with the vehicle, and/or disposed in or around the vehicle (e.g., a smart phone within the vehicle). Contextual information (i.e., information related to a context or a vehicle context of the sensor information) may also be acquired from sensors associated with (e.g., integral with or disposed in) the vehicle or from external data sources (e.g., other vehicles)” – therefore one or more sensor(s) inside or otherwise associated with the vehicle capture vehicle related sensor data these are one or more sensors associated with the subject (e.g., because the subject is driving the vehicle), 8:6-16 “the monitoring device 12 may receive the sensor information 32 and/or other information 33 (e.g., including contextual information) from the one or more other devices 23 (e.g., a driver's smartphone…device 23 may be a smartphone configured to provide the sensor information (e.g., vehicular movement data from integral gyroscopes within the device…” – may receive sensor data from sensors in the drivers smartphone (i.e., “sensor data captured by one or more sensors associated with the subject” , 5:8-16 “The monitoring system 11 may monitor the vehicle 10 via an interface with the vehicle 10 or as an integral part of the vehicle 10. In some embodiments, the system 11 includes a monitoring device 12, which may include integral sensors and/or couple to the vehicle 10 such that the monitoring device 12 may access sensor information provided from one or more separate sensors, such as sensors 16, 18, of the vehicle 10”)
With respect to claims 6 and 14, Kyne teaches the system of claim 1 and the method of claim 11;
wherein the subject is a driver to be insured, and (13:3-41 “the score is represented by a risk factor…indicating a higher risk associated with the driver…may be represented numerically…risk factor may be the basis for the insurer or the algorithm to determine and/or adjust the driver’s insurance premium…adjust the risk value based on the risk factor…difference between an original score and a current score” – therefore the subject being rated bay be an individual driver to be insured)
wherein the at least one processor is further programmed to apply the subject rating to an insurance underwriting process to generate an insurance policy associated with the driver 13:1-67 “monitoring device may send the vehicle information in the form of the score or an adjustment to the insurance premium…the score is represented by a risk factor…may generate a risk factor indicating a higher risk associated with the driver…may be represented numerically…risk factor may be the basis for the insurer or the algorithm to determine and/or adjust the driver’s insurance premium…adjust the risk value based on the risk factor…difference between an original score and a current score…may be configured to determine and/or adjust the driver’s insurance premium based on the risk factor…may leverage the risk factor to price usage-based insurance charges…usage-based insurance offers…offer coverage” – therefore the at least one processor is further programmed to apply the subject rating to an insurance underwriting process to generate an insurance policy associated with the driver (e.g., adjust/generate the driver’s insurance premium))
With respect to claims 7 and 19, Kyne teaches the system of claim 1 and the medium of claim 11;
wherein the subject rating is based in part upon the subject’s previous compliance with one or more previous recommendations (4:14-33 “in some embodiments, the driver is notified when the geographical location of the vehicle is considered high crime, traffic, or accident rate area…a route to exit such areas may be provided by the systems…driver may be proactively notified…and alternate routes to avoid such locations may be proactively offered. If the driver consistently avoids the high crime, traffic, or accident rate geographical location over time, then the driver may be rewarded by adjusting (reducing) the driver’s insurance premium…” – the system iteratively re-executes the risk factor/value scoring to generate updated risk factors/scores for the driver over time (i.e., generate an updated subject rating) which may involve analyzing sensor/contextual data associated with whether or not the driver consistently took the recommended alternate route(s) to avoid the risky area (i.e., the subject rating is based in part upon the subject’s previous compliance with one or more previous recommendations), 9:47-63 “calculated risk value or some other value based on the various pieces of information…calculate a risk value…data received by the monitoring device may be processed…to provide a potential change in…a related score…for viewing by the driver…to encourage a change in driving behavior” – scoring model(s) are iteratively re-executed to generate updated ratings/scores, 15:15-18 “the risk factor may be based at least in part on the historical information related to the vehicle and/or the driver” (historical and updated information used to iteratively calculate risk factor), 17:45-67 “The driver may adjust vehicle operation behaviors in an effort to minimize behaviors that result in increasing the driver's insurance premium and maximize behaviors that result in decreasing the driver's insurance premium…may reward or design its algorithm/ software to reward actions that show conscientious vehicle operation…if the driver consistently operates the vehicle 10 in a high crime geographical location, the monitoring device 12 may offer alternate routes to avoid the high crime geographical location. If the driver consistently avoids the high crime geographical location over time, then the driver may be rewarded by adjusting (i.e. reducing) the driver's insurance premium.”)
With respect to claim 8 and 20, Kyne teaches the system of claim 1 and the medium of claim 11;
wherein the plurality of data includes sensor data received from sensors disposed within at least one of a user computing device or a vehicle operated by the subject (2:33-59 “tracking operation of a vehicle (e.g., automobile, truck, motorcycle, RV, boat, airplane, snowmobile) and/or actions of a driver of the vehicle…incentivizing the driver to operate the vehicle in a safe manner…Sensor information related to the operation of the vehicle may be provided from sensors integral with systems of the vehicle, coupled with the vehicle, and/or disposed in or around the vehicle (e.g., a smart phone within the vehicle). Contextual information (i.e., information related to a context or a vehicle context of the sensor information) may also be acquired from sensors associated with (e.g., integral with or disposed in) the vehicle or from external data sources (e.g., other vehicles)” – therefore one or more sensor(s) inside the vehicle or from a smart phone of a user in the vehicle capture vehicle related sensor data and these are “sensors disposed within at least one of a user computing device or a vehicle operated by the subject” (e.g., because the subject is driving the vehicle), 5:8-16 “The monitoring system 11 may monitor the vehicle 10 via an interface with the vehicle 10 or as an integral part of the vehicle 10. In some embodiments, the system 11 includes a monitoring device 12, which may include integral sensors and/or couple to the vehicle 10 such that the monitoring device 12 may access sensor information provided from one or more separate sensors, such as sensors 16, 18, of the vehicle 10”)
With respect to claim 9, Kyne teaches the system of claim 1;
wherein the subject is an individual driver, and (13:3-41 “the score is represented by a risk factor…indicating a higher risk associated with the driver…may be represented numerically…risk factor may be the basis for the insurer or the algorithm to determine and/or adjust the driver’s insurance premium…adjust the risk value based on the risk factor…difference between an original score and a current score” – therefore the subject being rated bay be an individual driver)
wherein the at least one model performs a quantitative assessment of one or more driving behaviors of the driver based upon the plurality of data (13:3-41 “the score is represented by a risk factor…indicating a higher risk associated with the driver…may be represented numerically…risk factor may be the basis for the insurer or the algorithm to determine and/or adjust the driver’s insurance premium…adjust the risk value based on the risk factor…difference between an original score and a current score” – numerical score or risk factor means the model/algorithm performs a quantitative assessment of one or more driving behaviors of the driver based on the sensor/contextual data (i.e., based on the plurality of data))
With respect to claim 10, Kyne teaches the system of claim 9;
wherein the at least one processor is further programmed to receive the plurality of data in real-time during usage operation of a vehicle, the plurality of data corresponding to one or more driving behaviors of the driver (3:57-67 & 4:1-2 “embodiments may provide feedback to the driver (e.g., in real-time) in response to the sensor information and/or contextual information, which may encourage the driver to operate the vehicle within desirable parameters… Supply of such data in real-time (e.g., within a matter of seconds from measurement) may facilitate a game-type display of data that encourages drivers to drive within certain performance boundaries to achieve a desired score…”– therefore the sensor data may be received and processed in real time during operation of the vehicle to enable real-time feedback corresponding to one or more driving behaviors of the driver to be provided to the driver of the vehicle also in real-time (i.e., the system receives the data “in real-time during usage operation of a vehicle”) and the sensor/contextual data is “data corresponding to one or more driving behaviors of the driver”, 11:27-29 “The monitoring device 12 may send the vehicle information 40 synchronously ( e.g., constantly and/or as the vehicle information 40 becomes available)…therefore the data is received in real-time during operation of the vehicle, 12:4-7 “used to provide real-time feedback to the driver…inform that driver that the driver executed a sharp turn at an unsafe speed” 5:35-47 “factor based on statistical analysis, models, comparisons, or other evaluations… calculations (based on sensor data) to define factors or scores used in insurance adjustment……such calculations…provide drivers with rapid access to relevant insurance-related information (e.g.,…risk assessment based on driving data”, 13:63-67 “actual charges will apply based on monitored performance and real-time or essentially real-time updates to the cost (e.g., increases or decreases to the estimate) may be provided to the driver based on monitoring operational data and/or contextual information”)
With respect to claim 15, Kyne teaches the method of claim 11;
wherein the subject is an individual driver, (13:3-41 “the score is represented by a risk factor…indicating a higher risk associated with the driver…may be represented numerically…risk factor may be the basis for the insurer or the algorithm to determine and/or adjust the driver’s insurance premium…adjust the risk value based on the risk factor…difference between an original score and a current score” – therefore the subject being rated bay be an individual driver)
wherein the at least one model performs a quantitative assessment of one or more driving behaviors of the driver based upon the plurality of data, and (13:3-41 “the score is represented by a risk factor…indicating a higher risk associated with the driver…may be represented numerically…risk factor may be the basis for the insurer or the algorithm to determine and/or adjust the driver’s insurance premium…adjust the risk value based on the risk factor…difference between an original score and a current score” – numerical score or risk factor means the model/algorithm performs a quantitative assessment of one or more driving behaviors of the driver based on the sensor/contextual data (i.e., based on the plurality of data))
wherein the receiving a plurality of data comprises receiving the plurality of data in real-time during usage operation of a vehicle, the plurality of data corresponding to one or more driving behaviors of the driver (3:57-67 & 4:1-2 “embodiments may provide feedback to the driver (e.g., in real-time) in response to the sensor information and/or contextual information, which may encourage the driver to operate the vehicle within desirable parameters… Supply of such data in real-time (e.g., within a matter of seconds from measurement) may facilitate a game-type display of data that encourages drivers to drive within certain performance boundaries to achieve a desired score…”– therefore the sensor data may be received and processed in real time during operation of the vehicle to enable real-time feedback corresponding to one or more driving behaviors of the driver to be provided to the driver of the vehicle also in real-time (i.e., the system receives the data “in real-time during usage operation of a vehicle”) and the sensor/contextual data is “data corresponding to one or more driving behaviors of the driver”, 11:27-29 “The monitoring device 12 may send the vehicle information 40 synchronously ( e.g., constantly and/or as the vehicle information 40 becomes available)…therefore the data is received in real-time during operation of the vehicle, 12:4-7 “used to provide real-time feedback to the driver…inform that driver that the driver executed a sharp turn at an unsafe speed” 5:35-47 “factor based on statistical analysis, models, comparisons, or other evaluations… calculations (based on sensor data) to define factors or scores used in insurance adjustment……such calculations…provide drivers with rapid access to relevant insurance-related information (e.g.,…risk assessment based on driving data”, 13:63-67 “actual charges will apply based on monitored performance and real-time or essentially real-time updates to the cost (e.g., increases or decreases to the estimate) may be provided to the driver based on monitoring operational data and/or contextual information”)
v Claims 4 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Kyne in view of Friesen, as applied to claim 1 above, and further in view of Shipley (U.S. Patent No. 12,020,329 June 25, 2024- hereinafter "Shipley”)
With respect to claim 4, Kyne and Friesen teach the system of claim 1. Kyne does not appear to disclose,
wherein the subject performs the actions while operating on behalf of an on-demand platform, wherein the plurality of data includes evaluation criteria of the subject from the on-demand platform
However, Shipley discloses
wherein the subject performs the actions while operating on behalf of an on-demand platform, wherein the plurality of data includes evaluation criteria of the subject from the on-demand platform (8:10-24 “In tandem with receiving the vehicle data, the computing system 10 may receive data pertaining to the online-platform service task that the user intends to perform at block 46. The computing system 10 may receive online-platform service task data from the user device 26 or any other suitable device. The online service task data may include a type of online-platform service task the user intends to perform (e.g., ride sharing, food delivery, etc.), a user's rating associated with the online service task, specificities of the user's intended task (e.g., the user's intended route), and the like. In some embodiments, the specificities of the user's intended task may include further details pertaining to the user's intended route. For example, such specificities may include a calculated distance of the route, a calculated duration of time to complete the route, and so forth, 10:46-59 “If the computing system 10 determines that the user is performing an online-platform service task, the computing system 10 may proceed to block 70 and determine a pay-per-ride insurance rate for the user and the expected trip. In order to determine the pay-per-ride insurance rate, the computing system 10 may first retrieve data related to the task that the user is intending to perform. Such data may include the task's type, the user's intended destination, traffic patterns on the user's intended route, a day of time, the user's rating, and the like. The computing system 10 may retrieve the data from the user device 26. That is, the data may be retrieved from applications or software on the user device 26 such as an online-platform service work application, a maps application, and the like”
Shipley suggests it is advantageous to include wherein the subject performs the actions while operating on behalf of an on-demand platform, wherein the plurality of data includes evaluation criteria of the subject from the on-demand platform, because this data may further inform an aspect of the subject driving behavior and this evaluation criteria (user rating) may therefore be useful in determining or adjusting the subject’s insurance rates (8:10-24 & 10:46-59).
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 system of Kyne to include wherein the subject performs the actions while operating on behalf of an on-demand platform, wherein the plurality of data includes evaluation criteria of the subject from the on-demand platform, as taught by Shipley, because this data may further inform an aspect of the subject driving behavior and this evaluation criteria (user rating) may therefore be useful in determining or adjusting the subject’s insurance rates.
Furthermore, as in Shipley, it was within the capabilities of one of ordinary skill in the art to modify the system, method, and medium of Kyne in view of Friesen to include wherein the subject performs the actions while operating on behalf of an on-demand platform, wherein the plurality of data includes evaluation criteria of the subject from the on-demand platform. Furthermore, as in Shipley, the results of doing so would have been predictable to one of ordinary skill in the art. It would have been predictable to one of ordinary skill in the art that this data may further inform an aspect of the subject driving behavior and this evaluation criteria (user rating) may therefore be useful in determining or adjusting the subject’s insurance rates.
With respect to claim 5, Kyne and Friesen teach the system of claim 1. Kyne does not appear to disclose,
wherein the subject performs the actions while operating on behalf of an on-demand platform, and wherein the at least one processor is configured to detect, from the updated data, whether the subject is operating on behalf of the on-demand platform
However, Shipley discloses
wherein the subject performs the actions while operating on behalf of an on-demand platform, and wherein the at least one processor is configured to detect, from the updated data, whether the subject is operating on behalf of the on-demand platform (8:10-67 “In tandem with receiving the vehicle data, the computing system 10 may receive data pertaining to the online-platform service task that the user intends to perform at block 46. The computing system 10 may receive online-platform service task data from the user device 26 or any other suitable device. The online service task data may include a type of online-platform service task the user intends to perform (e.g., ride sharing, food delivery, etc.), a user's rating associated with the online service task, specificities of the user's intended task (e.g., the user's intended route), and the like. In some embodiments, the specificities of the user's intended task may include further details pertaining to the user's intended route. For example, such specificities may include a calculated distance of the route, a calculated duration of time to complete the route, and so forth… Keeping the foregoing in mind, the computing system 10 may monitor user activities relating to the user's performance of an online-platform service task. Such user activities may be related to the user's vehicular activity and the user's computational usage of online-platform service applications. The computing system 10 may use data pertaining to the user's activities to determine if the user is performing an online-platform service task. In this way, the computing system 10 may use this determination to adjust the user's pay-per-ride insurance rate. That is, the computing system 10 may holistically evaluate the task that the user is performing to adjust the user's pay-per-ride insurance rate in a manner that adequately covers the user's risk” – therefore the subject performs the actions while operating on behalf of an on-demand platform and the at least one processor is configured to detect, from the updated data, whether the subject is operating on behalf of the on-demand platform (e.g., so as to calculate/update the user’s pay-per-ride insurance based on their current operating activity), 10:46-59 “If the computing system 10 determines that the user is performing an online-platform service task, the computing system 10 may proceed to block 70 and determine a pay-per-ride insurance rate for the user and the expected trip. In order to determine the pay-per-ride insurance rate, the computing system 10 may first retrieve data related to the task that the user is intending to perform. Such data may include the task's type, the user's intended destination, traffic patterns on the user's intended route, a day of time, the user's rating, and the like. The computing system 10 may retrieve the data from the user device 26. That is, the data may be retrieved from applications or software on the user device 26 such as an online-platform service work application, a maps application, and the like”)
Shipley suggests it is advantageous to include wherein the subject performs the actions while operating on behalf of an on-demand platform, and wherein the at least one processor is configured to detect, from the updated data, whether the subject is operating on behalf of the on-demand platform, because this data may further inform an aspect of the subject driving behavior and this evaluation criteria (user rating) may therefore be useful in determining or adjusting the subject’s insurance rates such apay-per-ride insurance based on their current operating activity when the operator is a gig worker (8:10-24 & 10:46-59).
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 system of Kyne to include wherein the subject performs the actions while operating on behalf of an on-demand platform, and wherein the at least one processor is configured to detect, from the updated data, whether the subject is operating on behalf of the on-demand platform, as taught by Shipley, because this data may further inform an aspect of the subject driving behavior and this evaluation criteria (user rating) may therefore be useful in determining or adjusting the subject’s insurance rates such apay-per-ride insurance based on their current operating activity when the operator is a gig worker.
Furthermore, as in Shipley, it was within the capabilities of one of ordinary skill in the art to modify the system, method, and medium of Kyne in view of Friesen to include wherein the subject performs the actions while operating on behalf of an on-demand platform, and wherein the at least one processor is configured to detect, from the updated data, whether the subject is operating on behalf of the on-demand platform. Furthermore, as in Shipley, the results of doing so would have been predictable to one of ordinary skill in the art. It would have been predictable to one of ordinary skill in the art that this data may further inform an aspect of the subject driving behavior and this evaluation criteria (user rating) may therefore be useful in determining or adjusting the subject’s insurance rates such apay-per-ride insurance based on their current operating activity when the operator is a gig worker.
v Claims 13 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kyne in view of Friesen, as applied to claims 11 and 16 above, and further in view of Pak (U.S. PG Pub No. 2023/0186215 , June 15, 2023- hereinafter "Pak”)
With respect to claims 13 and 18, Kyne and Friesen teache the method of claim 11 and the medium of claim 16. Kyne does not appear to disclose,
wherein the subject performs the actions while operating on behalf of an on-demand platform, and wherein the at least one processor is further programmed to receive data associated with the actions from a third-party server associated with the on-demand platform
However, Pak discloses
wherein the subject performs the actions while operating on behalf of an on-demand platform, and wherein the at least one processor is further programmed to receive data associated with the actions from a third-party server associated with the on-demand platform ([0044] “car-sharing service provider server 21 is an operating server of a car-sharing service provider that has previously provided a vehicle rental service to the user terminal 30. There may be one or more car-sharing service providers. The car-sharing service provider server 21 may retain driving pattern data, member authority data, and profile data for the user” & [0060]-[0061] “The communication portion 120 may receive integrated data for a user from a car-sharing service provider server 21…The integrated data may include driving pattern data, accident history data, law violation data, driver's license data, member authority data, and profile data. The communication portion 120 receives driving pattern data, member authority data, and profile data for the user from the car-sharing service provider server 21” – therefore the driver/subject may perform driving actions while operating on behalf of an on-demand platform (e.g., car-sharing service), and wherein the at least one processor is further programmed to receive data associated with the actions from a third-party server associated with the on-demand platform (e.g., from the car-sharing service provider server))
As in Pak, it was within the capabilities of one of ordinary skill in the art to modify the system, method, and medium of Kyne in view of Friesen to include wherein the subject performs the actions while operating on behalf of an on-demand platform, and wherein the at least one processor is further programmed to receive data associated with the actions from a third-party server associated with the on-demand platform. Furthermore, as in Pak, the results of doing so would have been predictable to one of ordinary skill in the art. It would have been predictable to one of ordinary skill in the art that doing so would allow the system to obtain additional data associated with a history of the subject (e.g., additional driving behavior data) to supplement the data immediately available to the system such that the system has a more complete picture of the subject, as is needed in Kyne.
Prior Art of Record
The prior art made of record and not relied upon is considered pertinent to the applicant’s disclosure.
Oehler et al. (U.S. PG Pub No. 2022/0138700, May 5, 2022 - hereinafter "Oehler”) discloses receiving real-time vehicle sensor data and analyzing this data using one or more models to quantitatively assess a subject’s risk/driving score/grade. Discloses recommending actions to the driver that would reduce their risk and/or improve their rating. Discloses storing the sensor/telematics data and/or score/rating data on a blockchain. Also disclose use of smart contracts on the blockchain.
Gardner et al. (U.S. PG Pub No. 2020/0311698, October 1 2020) teaches minting and updating an NFT storing vehicle related information (e.g., driving behavior data)
Fuchs et al. (U.S. PG Pub No. 2019/0347739, November 14, 2019) teaches analyzing telematics data in real-time to generate various risk/driving scores/grades, recommending actions a driver may take to improve their score/grade (e.g., alternate safer route), monitoring whether or not they perform the recommended action, and updating their score/grade accordingly. Also disclose using the score/grade for usage-based insurance. ([0161]-[0167)) .
Dutta et al. (U.S. PG Pub No. 2020/0402149, December 24, 2020) teaches receiving real-time vehicle sensor data and analyzing this data using one or more models to quantitatively assess a subject’s risk/driving score/grade. Discloses storing the sensor/telematics data and/or score/rating data on a blockchain.
Tsujino et al. (U.S. PG Pub No. 2024/0046340, February 8, 2024) teaches minting and updating an NFT storing vehicle related information (e.g., driving behavior data).
Guttridge (U.S. PG Pub No 2020/0027183, January 23, 2020) teaches an on-demand platform that mints NFTs associated with respective vehicles and that store vehicle related information (e.g., safety scores).
Potter (U.S. Patent No 10,475,127 November 12, 2019) teaches receiving real-time vehicle sensor data and analyzing this data using one or more models to quantitatively assess a subject’s risk/driving score/grade. Discloses recommending actions to the driver that would reduce their risk and/or improve their rating. Discloses using the ratings/score to underwrite insurance.
“Who Is Collecting Data from Your Car?” (Keegan, Jon and Ng, Alfred; published July 27, 2022 at https://themarkup.org/the-breakdown/2022/07/27/who-is-collecting-data-from-your-car) discloses receiving real-time vehicle sensor data and analyzing this data using one or more models to quantitatively assess a subject’s risk/driving score/grade for various business uses.
Conclusion
No claim is allowed
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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