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 .
Status of Claims
This action is in reply to the amendments filed on 02/02/2026.
Claims 1-20 are currently pending and have been examined.
Claims 1, 8, and 15 are amended.
Claims 1-20 are currently rejected.
This action is made FINAL.
Response to Arguments
Applicant’s arguments filed 02/02/2026 have been fully considered but they are not persuasive.
In response to the terminal disclaimer filed 02/02/2026 the double patenting rejection is withdrawn.
Applicant argues that Russo is deficient in its teachings, specifically that the two different servers are calculating different statuses based on different thresholds. Russo teaches calculating two driver metrics, stars and shields, with the shield value requiring a higher threshold to achieve based on the same driver data. Russo also states in paragraph [0028] that “techniques for presenting driver performance metrics may be implemented in one or several client devices, a vehicle head unit, one or several network servers or a system that includes a combination of these devices”. Russo identifies that these calculations can be performed across multiple servers, especially if different entities have interest in the driver data, such as a vehicle manufactures and a driver insurance company. Therefore it would be obvious to have a different entity calculate their own metrics at their own servers. Purgatorio teaches having a user status linked between two servers and Krishna explicitly teach two servers performing calculations based on driver data. Jorn then teaches adjusting the access of vehicle features to a driver based on their skill level. This combination of art teaches all the claimed limitations and provide motivation for one to combine the arts as shown below.
Applicant additionally argues in sections a-e the mapping of Russo to the claims. These are not persuasive. Russo teaches in fig. 1B two servers, 10 and 58 that have a user status linked between the two (current star and shield level) that is then adjusted (increased) based on driving data as shown in at least fig. 3b. Russo also teaches sending by the second server the user status to permit access to a first set of features as shown in at least figs. 3c and 3d. Jorn also explicitly teaches receiving driver data to determine the driver performance. Russo also teaches providing access to features based on the results from the two servers because the specific combinations of star and shield levels would result in a unique combination of features as shown in figs, 3c and 3d. Applicant also is attacking the reference of Russo individually when the rejection as a whole is based on the combination of multiple references as shown below. Jorn also teaches each of these limitations as well as Krishna teaches the limitations argued in section d. On page 16 of applicant’s arguments they only make the general allegation that “Jorn, Purgatorio, and Krishna do not address the deficiencies of Russo.” Therefore applicant’s arguments are not persuasive and the rejections are being maintained as shown below.
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, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 6, 8-11, 13, 15-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Russo et. al. (US 2023/0132673), herein Russo in view of Jorn et. al. (DE 102009039774), herein “Jorn”, Purgatorio et. al. (US PAT NO 10,885,539), herein “Purgatorio”, and Krishna A G (US 2020/0079387), herein “Krishna”
Regarding claim 1:
Russo teaches:
A method (a method for presenting driver performance metrics [0008]) comprising:
receiving, by a first hardware-implemented server (examiner notes that in light of [0028] the client device 10 as shown in fig. 1B acts as a stand in for a server that could be the intermediary between the server 58 and the client device, replacing the application that is gathering and transmitting the data from the vehicle head unit 14 to the performance analysis server 58.), information about an event associated with an operation of a vehicle from a device of a user (vehicle data is obtained from the sensors 36 at the client device or the sensors 28 at the vehicle head unit 14 [0078]) having a user status linked to a second hardware-implemented server (fig. 1B, driver performance and analysis server 58) that is different than the first hardware-implemented server (techniques for presenting driver performance metrics may be implemented in one or several client devices, a vehicle head unit, one or several network servers or a system that includes a combination of these devices [0028]; In some implementations the vehicle data collection module 44 and/or the driver performance display module 48 can be a part of the driver performance analysis server 58, the client device 10, or a combination of the driver performance analysis server 58 and the client device 10. Although only one driver performance analysis server 58 is depicted in FIG. 1B, multiple driver performance analysis servers 58 may be provided for the purpose of distributing server load, serving different web pages, etc. These multiple driver performance analysis servers 58 may include a web server, an entity-specific server (e.g. an Apple® server, etc.), a server that is disposed in a retail or proprietary network, etc. For example, a first driver performance analysis server may include the driver performance scoring module 56 and a second driver performance analysis server 58 may include a web server or application server for generating and transmitting web pages or application screens. [0036]; although not explicitly stated, Russo states that one or multiple servers can be used in this process, making it obvious to one having ordinary skill in the art to apply different rating metrics at different servers depending on each servers prime directive or interests, such as a server by the vehicle manufacturer or a server by the insurance company that may have different performance metrics or risk thresholds.);
retrieving, by the first hardware-implemented server (fig. 1B, client device 10), the user status (the driver performance display module 48 may obtain indications of driver performance metrics for each of the telemetry factors from the driver performance analysis server 58 [0079]);
sending, by the second hardware-implemented server (fig. 1B, performance analysis server 58), the user status to the vehicle to permit the user to access a first set of features of the vehicle (FIG. 3C illustrates an exemplary display 330 presented by the driver performance application 40 indicating the benefits which may be provided to the user for reaching the star level. For example, one star may be exchanged for a free car wash. Three stars may be exchanged for an oil change and a safety inspection, and five stars may be exchanged for a $50 gas card. FIG. 3D illustrates an exemplary display 335 presented by the driver performance application 40 indicating the benefits which may be provided to the user for reaching the shield level. For example, one shield may be exchanged for glass repair. Two shields may be exchanged for a $100 deductible credit, and three shields may be exchanged for accident forgiveness. [0066]);
receiving, by the first hardware-implemented server (the vehicle data collection module 44 may compare the forward acceleration data to an acceleration threshold (e.g., 0.3 G) to determine whether a hard acceleration event occurred [0053]) and the second hardware-implemented server (the vehicle collection module 44 may transmit the raw vehicle data to the driver performance analysis server 58, and the driver performance analysis server 58 may compare the raw vehicle data to various thresholds to identify unsafe driving events [0053]), a value associated with an action performed by the vehicle during the event (the vehicle data collection module 44 may compare the forward acceleration data to an acceleration threshold (e.g., 0.3 G) to determine whether a hard acceleration event occurred. In response to identifying a hard acceleration event, the vehicle data collection module 44 may transmit information regarding the hard acceleration event to the driver performance analysis server 58, such as the type of unsafe driving event, the date and/or time of the unsafe driving event, the amount of time in which the vehicle accelerated above the threshold, etc. The vehicle data collection module 44 may transmit similar information for a speeding event, braking event, or maneuvering event. In other embodiments, the vehicle collection module 44 may transmit the raw vehicle data to the driver performance analysis server 58, and the driver performance analysis server 58 may compare the raw vehicle data to various thresholds to identify unsafe driving events. [0053]); and
based on a combination of a first output from the first hardware-implemented server and a second output from the second hardware-implemented server (techniques for presenting driver performance metrics may be implemented in one or several client devices, a vehicle head unit, one or several network servers or a system that includes a combination of these devices [0028]), determining whether to modify the user status by changing a number of features of the first set of features that can be accessed by the user (FIG. 3C illustrates an exemplary display 330 presented by the driver performance application 40 indicating the benefits which may be provided to the user for reaching the star level. For example, one star may be exchanged for a free car wash. Three stars may be exchanged for an oil change and a safety inspection, and five stars may be exchanged for a $50 gas card. FIG. 3D illustrates an exemplary display 335 presented by the driver performance application 40 indicating the benefits which may be provided to the user for reaching the shield level. For example, one shield may be exchanged for glass repair. Two shields may be exchanged for a $100 deductible credit, and three shields may be exchanged for accident forgiveness. [0066] [0066]) based on a first threshold range (the star level 302a includes an indication of a range of driver performance metrics 302c that corresponds to the star level 302a (e.g., from 70 to 89 out of 100) [0058]) [used by the first hardware-implemented server] and a second threshold range (the shield level 302a includes an indication of a range of driver performance metrics 304c that corresponds to the shield level 302a (e.g., from 90 to 100 out of 100) [0058]; examiner notes that Russo contains a typo calling the shield level 302a instead of 304a as is used in the figures.) [used by the second hardware-implemented server], wherein the second threshold range is greater than the first threshold range (star level is 70-89 and shield level is 90-100 as shown supra.).
Jorn also teaches:
A method (The invention relates to a method for controlling a motor vehicle, in particular for switching on and off and/or setting driving functions and/or performance features, and an associated motor vehicle. [0001]) comprising:
receiving, [by a first hardware-implemented server], information about an event associated with an operation of a vehicle from a device of a user (It should also be pointed out at this point that the method according to the invention naturally-unless otherwise explicitly stated-runs automatically in the motor vehicle, which of course also applies to the configurations discussed below. [0012]; Provision can be made for the driver to be identified before starting a journey, in particular by entering authentication information. [0013]; examiner is interpreting "initiating a vehicle event" as any event the starts the process of establishing the user and vehicle status for the next use of the vehicle which is inherently performed by Jorn when the vehicle is started/first accessed by the user and the vehicle accessing the profile of the user.)
retrieving, [by the first hardware-implemented server], the user status ([0013], "general profile"), wherein the user status controls which vehicle features can be accessed by the user (depending on the evaluation value, at least one performance feature available to the driver and/or at least one driving function of a system of the motor vehicle is activated or deactivated and/or at least one threshold value for an automatic driving intervention, in particular by a safety system, is adapted. [0007]);
receiving, by [the first hardware-implemented server and the second hardware implemented server], a value associated with an action ([0015], “"feedback" about his own performance.”; a time at high speeds and/or with regard to lane-changing processes and/or or steering behavior at high speeds. [0021]) performed by the vehicle (The motor vehicle itself therefore uses the driving activity of the driver in various driving situations to assess the driving ability of the driver and thus gives him, so to speak, "feedback" about his own performance. Consequently, for the continuous monitoring of the driving activity, measurement data describing the driving behavior of the driver are recorded and evaluated, for example by comparison with reference values and/or permitted intervals. This evaluation gives an indication of how the driver has behaved in the current, examined driving situation and thus of his driving ability. [0015]; examiner notes that the driver is being constantly monitored during their current driving session ("vehicle event")) during the event (the continuous monitoring of the driving activity [0015]);
Russo does not explicitly teach, however Jorn teaches:
sending, by the [second] hardware-implemented server (provision can be made on a voluntary basis for the evaluation value determined by motor vehicle 1 to be transmitted to an external device 19, where further evaluation is carried out centrally, so that evaluation values from drivers of different vehicles can also be examined there. [0053]; It is therefore conceivable, for example, that the evaluation value - possibly together with other information - can be transmitted to a driver's home computer [0031 ]), the user status (It is therefore proposed to provide the motor vehicle with information that provides information about the driving ability of the current driver. [0008]) to the vehicle to permit the user to access a first set of features of the vehicle (Viewed from a safety perspective, this means that driving functions and performance features may not yet be available to the driver, so that incorrect reactions and undesired driving states can be avoided. [0008]);
whether to modify the user status (For example, some driving functions and performance features can be activated less for the novice driver, but low threshold values for an automatic driving intervention can be provided, while an experienced driver can gain access to the entire range of services. Any possibilities are conceivable here. [0011]; examiner notes that the user has a score and proficiency level assigned to them ( e.g. "novice driver") which then corresponds to a series of functions of the vehicle that is available to the driver, which is the "vehicle status".) by changing a number of features of the first set of features that can be accessed by the user (by increasing or decreasing a number of features that may be operated by the user [0011])
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo to include the teachings as taught by Jorn to provide “a method for controlling a motor vehicle, in a particular driving functions, which enables operations of the motor vehicle to be better adapted to the individual driver” [Jorn, 0006].
Russo in view of Jorn does not explicitly teach, however Purgatorio teaches:
a first hardware-implemented server (fig. 1, computing device 100; fig. 2, the server-side computing device 100a)
having a user status linked (one or more of the application servers 205 may be configured to provide a service that receives telematics data from users and converts the telematics data into safe driving currency that may be used in various video games and/or with one or more other entities [col 10, lines 42-46]) to a second hardware-implemented server (fig. 2, application servers 205, servers 211) that is different than the first hardware-implemented server (fig. 1, computing device 100; fig. 2, the server-side computing device 100a);
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo and Jorn to include the teachings as taught by Purgatorio to provide systems and methods for awarding drivers electronic safe driving currency (e.g., driving points) for safe operation of a vehicle for use in purchasing electronic and real-world user-selectable benefits; systems and methods for discovering establishments along a user's route at which a driver may purchase such benefits; systems and methods for obtaining safe driving currency by winning safe driving tournaments; systems and methods for obtaining a driving score of a public transport as a rider approaches the public transport; and systems and methods for using gaming behavior to determine an insurance premium [Purgatorio, abstract].
Krishna also teaches:
having a user status linked to a second hardware-implemented server (fig. 2, onboard detection device 110) that is different than the first hardware-implemented server (fig. 2, cloud server 118);
Russo in view of Jorn and Purgatorio does not explicitly teach, however Krishna teaches:
receiving, by the first hardware-implemented server (fig. 2, on-board detection device 110, steps 215-225) and the second hardware-implemented server (fig. 2, cloud server 118, steps 230 and 235), a value associated with an action performed by the vehicle during the event (At 215, on-board detection device 110 facilitates recording of media data and multisensory data during a trip of a vehicle. A plurality of cameras mounted on the vehicle are used to record the media data which comprises of audio and visual data of a driving scene and a plurality of sensors positioned in the vehicle are used to record multisensory data such as, but not limited to, the speed, the acceleration force, location, the deceleration force etc. The media data may comprise a plurality of image frames and the sensory data may comprise of values recorded by the sensors and some graphs and traces. [0067]; At 230, the on-board detection device 110 is configured to send the metadata related to the detected event to a cloud server 118. In one embodiment, the metadata may comprise data such as the time and date of occurrence of the event, location of occurrence, an image frame from the plurality of image frames. In some embodiments, the image frame received in the metadata may depict most important image for determining the event occurrence. [0070]); and
based on a combination (fig. 2, step 255 requires both step 225 and step 245 to occur and baes the performance based upon the combination of those results.) of a first output from the first hardware-implemented server (fig. 2, step 225) and a second output from the second hardware-implemented server (Further at 245, the cloud server 118 is configured to verify or auto-review all the events that were previously detected by the on-board detection device. The method of verifying all the detected events received by the on-board detection device is termed as ‘Auto Review’. The verification of the detected events may be done after each trip and in some embodiments, the verification may be done on-demand based on a request received from a driver through on-board detection device. [0073]), determining whether to modify the user status by changing a number of features of the first set of features that can be accessed by the user (At 255, the cloud server 118 is configured to calculate a performance score of the driver 108. The performance score of the driver 108 is calculated after each trip based on a number of detected events, weight coefficients corresponding to the number of detected events and a total distance travelled by the driver in the trip. [0075]) based on a first threshold range used by the first hardware-implemented server (At 225, the on-board detection device 110 is configured to detect an event occurrence based on the generated metadata and the set of configuration parameters received from the fleet manager device. For example, if the threshold for a speed violation in the set of configuration parameters is 70 Kmph and the driver has crossed the limit and has driven the vehicle in 80 Kmph, the on-board detection device 110 detects an event of speed violation based on the generated metadata in real time. [0069]) and a second threshold range used by the second hardware-implemented server (Further at 245, the cloud server 118 is configured to verify or auto-review all the events that were previously detected by the on-board detection device. The method of verifying all the detected events received by the on-board detection device is termed as ‘Auto Review’. The verification of the detected events may be done after each trip and in some embodiments, the verification may be done on-demand based on a request received from a driver through on-board detection device. [0073]; At the vehicle side, it is not convenient to use complex algorithms for event detection, as a result, there is a high probability of false event detection at the on-board detection device. To overcome this problem, the cloud server verifies detection of the detected event by utilizing computationally complex event detection and sophisticated algorithms for reliable detection. More specifically, the cloud server may utilize computer vision, machine learning and artificial intelligence techniques for detecting objects/events of interest and ensures compliance. [0035])
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo in view of Jorn and Purgatorio to include the teachings as taught by Krishna because “the same configuration parameters are also sent to the cloud server 118. The cloud server 118 is used to verify the detected events using more sophisticated algorithms in order to auto-review the detected events. In one embodiment, at the start of every trip, and during every trip at certain intervals, the fleet manager device polls configuration settings on the cloud server to ensure that the correct compliance numbers and metrics are enforced [Krishna, 0066]”.
Regarding claim 2:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 1, upon which this claim is dependent.
Russo further teaches:
wherein the action is identified by a sensor of the vehicle (a vehicle head unit to receive the vehicle data from sensors at the head unit [0028]),
Regarding claim 3:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 1, upon which this claim is dependent.
Russo further teaches:
comparing the action to a set of predetermined vehicle actions to determine the value (the client device 10 transmits raw vehicle data to the driver performance analysis server 58, and the driver performance analysis server 58 may compare the raw vehicle data to a braking, speeding, acceleration, or maneuvering threshold to identify an unsafe driving event. [0042]);
identifying that the value is within the first threshold range (when the braking score is between 70 and 89, the braking score counts toward the star level score but does not count toward the shield level score [0045]) and the second threshold range (When the braking score is above 90, the braking score counts toward both the star level and the shield level scores [0045]);
Jorn further teaches:
and increasing the user status (The evaluation value is then determined accordingly, for example increased by a certain number of points. [0020]) to an increased user status in response to the value being within the first threshold range and the second threshold range (The data from a wide variety of sensors and systems can be taken into account, for example acceleration sensors, steering angle sensors, environment sensors such as radar sensors, ultrasonic sensors, optical sensors and the like. The information from these sensors and driver assistance systems is combined and evaluated in order, for example, to identify a driving situation and the driving behavior of the driver in the driving situation and then to evaluate them, for example by comparing them with threshold values or intervals. [0020]).
Krishna further teaches:
identifying that the value is within the first threshold range (At 225, the on-board detection device 110 is configured to detect an event occurrence based on the generated metadata and the set of configuration parameters received from the fleet manager device. For example, if the threshold for a speed violation in the set of configuration parameters is 70 Kmph and the driver has crossed the limit and has driven the vehicle in 80 Kmph, the on-board detection device 110 detects an event of speed violation based on the generated metadata in real time. [0069]) and the second threshold range (Further at 245, the cloud server 118 is configured to verify or auto-review all the events that were previously detected by the on-board detection device. The method of verifying all the detected events received by the on-board detection device is termed as ‘Auto Review’. The verification of the detected events may be done after each trip and in some embodiments, the verification may be done on-demand based on a request received from a driver through on-board detection device. [0073]; At the vehicle side, it is not convenient to use complex algorithms for event detection, as a result, there is a high probability of false event detection at the on-board detection device. To overcome this problem, the cloud server verifies detection of the detected event by utilizing computationally complex event detection and sophisticated algorithms for reliable detection. More specifically, the cloud server may utilize computer vision, machine learning and artificial intelligence techniques for detecting objects/events of interest and ensures compliance. [0035]);
Regarding claim 4:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 3, upon which this claim is dependent.
Jorn further teaches:
sending the increased user status to the vehicle to control the vehicle to permit the user access to a second set of vehicle features (This also applies to the example of novice drivers, who can drive highly powered vehicles and, over time, gain incremental access to features and driving functions that require higher driving skills. [0010]; some driving functions and performance features can be activated less for the novice driver, but low threshold values for an automatic driving intervention can be provided, while an experienced driver can gain access to the entire range of services. Any possibilities are conceivable here. [0011]) comprising one or more vehicle features that were not accessible under the user status (while an experienced driver can gain access to the entire range of services [0011]).
Regarding claim 6:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 3, upon which this claim is dependent.
Jorn further teaches:
updating a user profile (The evaluation value related to all journeys by a driver with the motor vehicle is expediently stored, which means it is continued over several journeys. [0015]) with the increased user status (This evaluation gives an indication of how the driver has behaved in the current, examined driving situation and thus of his driving ability. Evaluations of several such situations, which can be mapped, for example, via a situation value, in particular a score achieved, are then included in the update of the evaluation value [0015]).
Regarding claim 8:
Russo teaches:
A system (A method and system may present indications of driver performance metrics on a user interface of a client device based on vehicle data for a user collected over a time interval [abstract]) comprising:
a first hardware-implemented server (examiner notes that in light of [0028] the client device 10 as shown in fig. 1B acts as a stand in for a server that could be the intermediary between the server 58 and the client device, replacing the application that is gathering and transmitting the data from the vehicle head unit 14 to the performance analysis server 58.) configured to:
receive information about an event associated with an operation of a vehicle from a device of a user (vehicle data is obtained from the sensors 36 at the client device or the sensors 28 at the vehicle head unit 14 [0078]);
retrieve a user status of the user (the driver performance display module 48 may obtain indications of driver performance metrics for each of the telemetry factors from the driver performance analysis server 58 [0079]), wherein the user status is linked to a second hardware-implemented server (fig. 1B, driver performance and analysis server 58) that is different than the first hardware-implemented server, wherein the second hardware-implemented server (fig. 1B, performance analysis server 58) is configured to:
send the user status to the vehicle to permit the user to access a first set of features of the vehicle (FIG. 3C illustrates an exemplary display 330 presented by the driver performance application 40 indicating the benefits which may be provided to the user for reaching the star level. For example, one star may be exchanged for a free car wash. Three stars may be exchanged for an oil change and a safety inspection, and five stars may be exchanged for a $50 gas card. FIG. 3D illustrates an exemplary display 335 presented by the driver performance application 40 indicating the benefits which may be provided to the user for reaching the shield level. For example, one shield may be exchanged for glass repair. Two shields may be exchanged for a $100 deductible credit, and three shields may be exchanged for accident forgiveness. [0066]);
wherein both the first hardware-implemented server (the vehicle data collection module 44 may compare the forward acceleration data to an acceleration threshold (e.g., 0.3 G) to determine whether a hard acceleration event occurred [0053]) and the second hardware-implemented server (the vehicle collection module 44 may transmit the raw vehicle data to the driver performance analysis server 58, and the driver performance analysis server 58 may compare the raw vehicle data to various thresholds to identify unsafe driving events [0053]) are configured to:
receive a value associated with an action performed by the vehicle during the event (the vehicle data collection module 44 may compare the forward acceleration data to an acceleration threshold (e.g., 0.3 G) to determine whether a hard acceleration event occurred. In response to identifying a hard acceleration event, the vehicle data collection module 44 may transmit information regarding the hard acceleration event to the driver performance analysis server 58, such as the type of unsafe driving event, the date and/or time of the unsafe driving event, the amount of time in which the vehicle accelerated above the threshold, etc. The vehicle data collection module 44 may transmit similar information for a speeding event, braking event, or maneuvering event. In other embodiments, the vehicle collection module 44 may transmit the raw vehicle data to the driver performance analysis server 58, and the driver performance analysis server 58 may compare the raw vehicle data to various thresholds to identify unsafe driving events. [0053]); and
based on a combination of a first output from the first hardware-implemented server and a second output from the second hardware-implemented server (techniques for presenting driver performance metrics may be implemented in one or several client devices, a vehicle head unit, one or several network servers or a system that includes a combination of these devices [0028]), determine whether to modify the user status by changing a number of features of the first set of features that can be accessed by the user (FIG. 3C illustrates an exemplary display 330 presented by the driver performance application 40 indicating the benefits which may be provided to the user for reaching the star level. For example, one star may be exchanged for a free car wash. Three stars may be exchanged for an oil change and a safety inspection, and five stars may be exchanged for a $50 gas card. FIG. 3D illustrates an exemplary display 335 presented by the driver performance application 40 indicating the benefits which may be provided to the user for reaching the shield level. For example, one shield may be exchanged for glass repair. Two shields may be exchanged for a $100 deductible credit, and three shields may be exchanged for accident forgiveness. [0066] [0066]) based on a first threshold range (the star level 302a includes an indication of a range of driver performance metrics 302c that corresponds to the star level 302a (e.g., from 70 to 89 out of 100) [0058]) [used by the first hardware-implemented server] and a second threshold range (the shield level 302a includes an indication of a range of driver performance metrics 304c that corresponds to the shield level 302a (e.g., from 90 to 100 out of 100) [0058]; examiner notes that Russo contains a typo calling the shield level 302a instead of 304a as is used in the figures.) [used by the second hardware-implemented server], wherein the second threshold range is greater than the first threshold range (star level is 70-89 and shield level is 90-100 as shown supra.).
Jorn also teaches:
receive information about an event associated with an operation of a vehicle from a device of a user (It should also be pointed out at this point that the method according to the invention naturally-unless otherwise explicitly stated-runs automatically in the motor vehicle, which of course also applies to the configurations discussed below. [0012]; Provision can be made for the driver to be identified before starting a journey, in particular by entering authentication information. [0013]; examiner is interpreting "initiating a vehicle event" as any event the starts the process of establishing the user and vehicle status for the next use of the vehicle which is inherently performed by Jorn when the vehicle is started/first accessed by the user and the vehicle accessing the profile of the user.)
receive a value associated with an action ([0015], “"feedback" about his own performance.”; a time at high speeds and/or with regard to lane-changing processes and/or or steering behavior at high speeds. [0021]) performed by the vehicle (The motor vehicle itself therefore uses the driving activity of the driver in various driving situations to assess the driving ability of the driver and thus gives him, so to speak, "feedback" about his own performance. Consequently, for the continuous monitoring of the driving activity, measurement data describing the driving behavior of the driver are recorded and evaluated, for example by comparison with reference values and/or permitted intervals. This evaluation gives an indication of how the driver has behaved in the current, examined driving situation and thus of his driving ability. [0015]; examiner notes that the driver is being constantly monitored during their current driving session ("vehicle event")) during the event (the continuous monitoring of the driving activity [0015]);
Russo does not explicitly teach, however Jorn teaches:
controls which vehicle features can be accessed by the user (depending on the evaluation value, at least one performance feature available to the driver and/or at least one driving function of a system of the motor vehicle is activated or deactivated and/or at least one threshold value for an automatic driving intervention, in particular by a safety system, is adapted. [0007]);
send the user status (It is therefore proposed to provide the motor vehicle with information that provides information about the driving ability of the current driver. [0008]) to the vehicle to permit the user to access a first set of features of the vehicle (Viewed from a safety perspective, this means that driving functions and performance features may not yet be available to the driver, so that incorrect reactions and undesired driving states can be avoided. [0008]);
whether to modify the user status (For example, some driving functions and performance features can be activated less for the novice driver, but low threshold values for an automatic driving intervention can be provided, while an experienced driver can gain access to the entire range of services. Any possibilities are conceivable here. [0011]; examiner notes that the user has a score and proficiency level assigned to them ( e.g. "novice driver") which then corresponds to a series of functions of the vehicle that is available to the driver, which is the "vehicle status".) by changing a number of features of the first set of features that can be accessed by the user (by increasing or decreasing a number of features that may be operated by the user [0011])
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo to include the teachings as taught by Jorn to provide “a method for controlling a motor vehicle, in a particular driving functions, which enables operations of the motor vehicle to be better adapted to the individual driver” [Jorn, 0006].
Russo in view of Jorn does not explicitly teach, however Purgatorio teaches:
a first hardware-implemented server (fig. 1, computing device 100; fig. 2, the server-side computing device 100a)
having a user status linked (one or more of the application servers 205 may be configured to provide a service that receives telematics data from users and converts the telematics data into safe driving currency that may be used in various video games and/or with one or more other entities [col 10, lines 42-46]) to a second hardware-implemented server (fig. 2, application servers 205, servers 211) that is different than the first hardware-implemented server (fig. 1, computing device 100; fig. 2, the server-side computing device 100a);
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo and Jorn to include the teachings as taught by Purgatorio to provide systems and methods for awarding drivers electronic safe driving currency (e.g., driving points) for safe operation of a vehicle for use in purchasing electronic and real-world user-selectable benefits; systems and methods for discovering establishments along a user's route at which a driver may purchase such benefits; systems and methods for obtaining safe driving currency by winning safe driving tournaments; systems and methods for obtaining a driving score of a public transport as a rider approaches the public transport; and systems and methods for using gaming behavior to determine an insurance premium [Purgatorio, abstract].
Krishna also teaches:
having a user status linked to a second hardware-implemented server (fig. 2, onboard detection device 110) that is different than the first hardware-implemented server (fig. 2, cloud server 118);
Russo in view of Jorn and Purgatorio does not explicitly teach, however Krishna teaches:
wherein both the first hardware-implemented server (fig. 2, on-board detection device 110, steps 215-225) and the second hardware-implemented server (fig. 2, cloud server 118, steps 230 and 235) are configured to:
receive a value associated with an action performed by the vehicle during the event (At 215, on-board detection device 110 facilitates recording of media data and multisensory data during a trip of a vehicle. A plurality of cameras mounted on the vehicle are used to record the media data which comprises of audio and visual data of a driving scene and a plurality of sensors positioned in the vehicle are used to record multisensory data such as, but not limited to, the speed, the acceleration force, location, the deceleration force etc. The media data may comprise a plurality of image frames and the sensory data may comprise of values recorded by the sensors and some graphs and traces. [0067]; At 230, the on-board detection device 110 is configured to send the metadata related to the detected event to a cloud server 118. In one embodiment, the metadata may comprise data such as the time and date of occurrence of the event, location of occurrence, an image frame from the plurality of image frames. In some embodiments, the image frame received in the metadata may depict most important image for determining the event occurrence. [0070])
based on a combination (fig. 2, step 255 requires both step 225 and step 245 to occur and baes the performance based upon the combination of those results.) of a first output from the first hardware-implemented server (fig. 2, step 225) and a second output from the second hardware-implemented server (Further at 245, the cloud server 118 is configured to verify or auto-review all the events that were previously detected by the on-board detection device. The method of verifying all the detected events received by the on-board detection device is termed as ‘Auto Review’. The verification of the detected events may be done after each trip and in some embodiments, the verification may be done on-demand based on a request received from a driver through on-board detection device. [0073]), determining whether to modify the user status by changing a number of features of the first set of features that can be accessed by the user (At 255, the cloud server 118 is configured to calculate a performance score of the driver 108. The performance score of the driver 108 is calculated after each trip based on a number of detected events, weight coefficients corresponding to the number of detected events and a total distance travelled by the driver in the trip. [0075]) based on a first threshold range used by the first hardware-implemented server (At 225, the on-board detection device 110 is configured to detect an event occurrence based on the generated metadata and the set of configuration parameters received from the fleet manager device. For example, if the threshold for a speed violation in the set of configuration parameters is 70 Kmph and the driver has crossed the limit and has driven the vehicle in 80 Kmph, the on-board detection device 110 detects an event of speed violation based on the generated metadata in real time. [0069]) and a second threshold range used by the second hardware-implemented server (Further at 245, the cloud server 118 is configured to verify or auto-review all the events that were previously detected by the on-board detection device. The method of verifying all the detected events received by the on-board detection device is termed as ‘Auto Review’. The verification of the detected events may be done after each trip and in some embodiments, the verification may be done on-demand based on a request received from a driver through on-board detection device. [0073]; At the vehicle side, it is not convenient to use complex algorithms for event detection, as a result, there is a high probability of false event detection at the on-board detection device. To overcome this problem, the cloud server verifies detection of the detected event by utilizing computationally complex event detection and sophisticated algorithms for reliable detection. More specifically, the cloud server may utilize computer vision, machine learning and artificial intelligence techniques for detecting objects/events of interest and ensures compliance. [0035])
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo in view of Jorn and Purgatorio to include the teachings as taught by Krishna because “the same configuration parameters are also sent to the cloud server 118. The cloud server 118 is used to verify the detected events using more sophisticated algorithms in order to auto-review the detected events. In one embodiment, at the start of every trip, and during every trip at certain intervals, the fleet manager device polls configuration settings on the cloud server to ensure that the correct compliance numbers and metrics are enforced [Krishna, 0066]”.
Regarding claim 9:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 8, upon which this claim is dependent.
Russo further teaches:
wherein the action is identified by a sensor of the vehicle (a vehicle head unit to receive the vehicle data from sensors at the head unit [0028]),
Regarding claim 10:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 8, upon which this claim is dependent.
Russo further teaches:
comparing the action to a set of predetermined vehicle actions to determine the value (the client device 10 transmits raw vehicle data to the driver performance analysis server 58, and the driver performance analysis server 58 may compare the raw vehicle data to a braking, speeding, acceleration, or maneuvering threshold to identify an unsafe driving event. [0042]);
identifying that the value is within the first threshold range (when the braking score is between 70 and 89, the braking score counts toward the star level score but does not count toward the shield level score [0045]) and the second threshold range (When the braking score is above 90, the braking score counts toward both the star level and the shield level scores [0045]);
Jorn further teaches:
comparing the action to a set of predetermined vehicle actions to determine the value (The information from these sensors and driver assistance systems is combined and evaluated in order, for example, to identify a driving situation and the driving behavior of the driver in the driving situation and then to evaluate them, for example by comparing them with threshold values or intervals. [0020]);
identifying that the value is within the first threshold range (Provision can be made for specific configurations of performance features and/or driving functions and/or threshold values to be assigned to specific values and/or value ranges for the evaluation value. [0011]) and the second threshold range (examiner notes that using both servers to make the same calculation is simply a supplication of parts to provide the expected benefit of data validation and comparison that is shown as a known benefit by at least Krishna as shown below. See MPEP 2144.04(VI)(B).);
and increasing the user status (The evaluation value is then determined accordingly, for example increased by a certain number of points. [0020]) to an increased user status in response to the value being within the first threshold range and the second threshold range (The data from a wide variety of sensors and systems can be taken into account, for example acceleration sensors, steering angle sensors, environment sensors such as radar sensors, ultrasonic sensors, optical sensors and the like. The information from these sensors and driver assistance systems is combined and evaluated in order, for example, to identify a driving situation and the driving behavior of the driver in the driving situation and then to evaluate them, for example by comparing them with threshold values or intervals. [0020]).
Krishna further teaches:
identifying that the value is within the first threshold range (At 225, the on-board detection device 110 is configured to detect an event occurrence based on the generated metadata and the set of configuration parameters received from the fleet manager device. For example, if the threshold for a speed violation in the set of configuration parameters is 70 Kmph and the driver has crossed the limit and has driven the vehicle in 80 Kmph, the on-board detection device 110 detects an event of speed violation based on the generated metadata in real time. [0069]) and the second threshold range (Further at 245, the cloud server 118 is configured to verify or auto-review all the events that were previously detected by the on-board detection device. The method of verifying all the detected events received by the on-board detection device is termed as ‘Auto Review’. The verification of the detected events may be done after each trip and in some embodiments, the verification may be done on-demand based on a request received from a driver through on-board detection device. [0073]; At the vehicle side, it is not convenient to use complex algorithms for event detection, as a result, there is a high probability of false event detection at the on-board detection device. To overcome this problem, the cloud server verifies detection of the detected event by utilizing computationally complex event detection and sophisticated algorithms for reliable detection. More specifically, the cloud server may utilize computer vision, machine learning and artificial intelligence techniques for detecting objects/events of interest and ensures compliance. [0035]);
Regarding claim 11:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 10, upon which this claim is dependent.
Jorn further teaches:
send the increased user status to the vehicle to control the vehicle to permit the user access to a second set of vehicle features (This also applies to the example of novice drivers, who can drive highly powered vehicles and, over time, gain incremental access to features and driving functions that require higher driving skills. [0010]; some driving functions and performance features can be activated less for the novice driver, but low threshold values for an automatic driving intervention can be provided, while an experienced driver can gain access to the entire range of services. Any possibilities are conceivable here. [0011]) comprising one or more vehicle features that were not accessible under the user status (while an experienced driver can gain access to the entire range of services [0011]).
Regarding claim 13:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 10, upon which this claim is dependent.
Jorn further teaches:
and update a user profile (The evaluation value related to all journeys by a driver with the motor vehicle is expediently stored, which means it is continued over several journeys. [0015]) with the increased user status (This evaluation gives an indication of how the driver has behaved in the current, examined driving situation and thus of his driving ability. Evaluations of several such situations, which can be mapped, for example, via a situation value, in particular a score achieved, are then included in the update of the evaluation value [0015]).
Regarding claim 15:
Russo teaches:
A non-transitory computer readable medium comprising one or more instructions that when executed by a processor cause the processors (The controller may include a program memory 60, a microcontroller or a microprocessor (MP), a random-access memory (RAM), and/or an input/output (I/O) circuit, all of which may be interconnected via an address/data bus. In some embodiments, the controller may also include, or otherwise be communicatively connected to, a database or other data storage mechanism (e.g., one or more hard disk drives, optical storage drives, solid state storage devices, etc.), such as a user profile database 64. [0037]) to perform
receiving, by a first hardware-implemented server (examiner notes that in light of [0028] the client device 10 as shown in fig. 1B acts as a stand in for a server that could be the intermediary between the server 58 and the client device, replacing the application that is gathering and transmitting the data from the vehicle head unit 14 to the performance analysis server 58.), information about an event associated with an operation of a vehicle from a device of a user (vehicle data is obtained from the sensors 36 at the client device or the sensors 28 at the vehicle head unit 14 [0078]) having a user status linked to a second hardware-implemented server (fig. 1B, driver performance and analysis server 58) that is different than the first hardware-implemented server (techniques for presenting driver performance metrics may be implemented in one or several client devices, a vehicle head unit, one or several network servers or a system that includes a combination of these devices [0028]; In some implementations the vehicle data collection module 44 and/or the driver performance display module 48 can be a part of the driver performance analysis server 58, the client device 10, or a combination of the driver performance analysis server 58 and the client device 10. Although only one driver performance analysis server 58 is depicted in FIG. 1B, multiple driver performance analysis servers 58 may be provided for the purpose of distributing server load, serving different web pages, etc. These multiple driver performance analysis servers 58 may include a web server, an entity-specific server (e.g. an Apple® server, etc.), a server that is disposed in a retail or proprietary network, etc. For example, a first driver performance analysis server may include the driver performance scoring module 56 and a second driver performance analysis server 58 may include a web server or application server for generating and transmitting web pages or application screens. [0036]; although not explicitly stated, Russo states that one or multiple servers can be used in this process, making it obvious to one having ordinary skill in the art to apply different rating metrics at different servers depending on each servers prime directive or interests, such as a server by the vehicle manufacturer or a server by the insurance company that may have different performance metrics or risk thresholds.);
retrieving, by the first hardware-implemented server (fig. 1B, client device 10), the user status (the driver performance display module 48 may obtain indications of driver performance metrics for each of the telemetry factors from the driver performance analysis server 58 [0079]);
sending, by the second hardware-implemented server (fig. 1B, performance analysis server 58), the user status to the vehicle to permit the user to access a first set of features of the vehicle (FIG. 3C illustrates an exemplary display 330 presented by the driver performance application 40 indicating the benefits which may be provided to the user for reaching the star level. For example, one star may be exchanged for a free car wash. Three stars may be exchanged for an oil change and a safety inspection, and five stars may be exchanged for a $50 gas card. FIG. 3D illustrates an exemplary display 335 presented by the driver performance application 40 indicating the benefits which may be provided to the user for reaching the shield level. For example, one shield may be exchanged for glass repair. Two shields may be exchanged for a $100 deductible credit, and three shields may be exchanged for accident forgiveness. [0066]);
receiving, by the first hardware-implemented server (the vehicle data collection module 44 may compare the forward acceleration data to an acceleration threshold (e.g., 0.3 G) to determine whether a hard acceleration event occurred [0053]) and the second hardware-implemented server (the vehicle collection module 44 may transmit the raw vehicle data to the driver performance analysis server 58, and the driver performance analysis server 58 may compare the raw vehicle data to various thresholds to identify unsafe driving events [0053]), a value associated with an action performed by the vehicle during the event (the vehicle data collection module 44 may compare the forward acceleration data to an acceleration threshold (e.g., 0.3 G) to determine whether a hard acceleration event occurred. In response to identifying a hard acceleration event, the vehicle data collection module 44 may transmit information regarding the hard acceleration event to the driver performance analysis server 58, such as the type of unsafe driving event, the date and/or time of the unsafe driving event, the amount of time in which the vehicle accelerated above the threshold, etc. The vehicle data collection module 44 may transmit similar information for a speeding event, braking event, or maneuvering event. In other embodiments, the vehicle collection module 44 may transmit the raw vehicle data to the driver performance analysis server 58, and the driver performance analysis server 58 may compare the raw vehicle data to various thresholds to identify unsafe driving events. [0053]); and
based on a combination of a first output from the first hardware-implemented server and a second output from the second hardware-implemented server (techniques for presenting driver performance metrics may be implemented in one or several client devices, a vehicle head unit, one or several network servers or a system that includes a combination of these devices [0028]), determining whether to modify the user status by changing a number of features of the first set of features that can be accessed by the user (FIG. 3C illustrates an exemplary display 330 presented by the driver performance application 40 indicating the benefits which may be provided to the user for reaching the star level. For example, one star may be exchanged for a free car wash. Three stars may be exchanged for an oil change and a safety inspection, and five stars may be exchanged for a $50 gas card. FIG. 3D illustrates an exemplary display 335 presented by the driver performance application 40 indicating the benefits which may be provided to the user for reaching the shield level. For example, one shield may be exchanged for glass repair. Two shields may be exchanged for a $100 deductible credit, and three shields may be exchanged for accident forgiveness. [0066] [0066]) based on a first threshold range (the star level 302a includes an indication of a range of driver performance metrics 302c that corresponds to the star level 302a (e.g., from 70 to 89 out of 100) [0058]) [used by the first hardware-implemented server] and a second threshold range (the shield level 302a includes an indication of a range of driver performance metrics 304c that corresponds to the shield level 302a (e.g., from 90 to 100 out of 100) [0058]; examiner notes that Russo contains a typo calling the shield level 302a instead of 304a as is used in the figures.) [used by the second hardware-implemented server], wherein the second threshold range is greater than the first threshold range (star level is 70-89 and shield level is 90-100 as shown supra.).
Jorn also teaches:
A non-transitory computer readable medium comprising one or more instructions that when executed by a processor cause the processors to perform (In addition to the method, the present invention also relates to a motor vehicle, comprising a control device that is designed to carry out the method according to the invention. [0035]; examiner notes that the control device would inherently contain a storage medium that contains a program that is read and run by the processor.):
receiving, [by a first hardware-implemented server], information about an event associated with an operation of a vehicle from a device of a user (It should also be pointed out at this point that the method according to the invention naturally-unless otherwise explicitly stated-runs automatically in the motor vehicle, which of course also applies to the configurations discussed below. [0012]; Provision can be made for the driver to be identified before starting a journey, in particular by entering authentication information. [0013]; examiner is interpreting "initiating a vehicle event" as any event the starts the process of establishing the user and vehicle status for the next use of the vehicle which is inherently performed by Jorn when the vehicle is started/first accessed by the user and the vehicle accessing the profile of the user.)
retrieving, [by the first hardware-implemented server], the user profile of the user status ([0013], "general profile"), wherein the user status controls which vehicle features can be accessed by the user (depending on the evaluation value, at least one performance feature available to the driver and/or at least one driving function of a system of the motor vehicle is activated or deactivated and/or at least one threshold value for an automatic driving intervention, in particular by a safety system, is adapted. [0007]);
receiving, by [the first hardware-implemented server and the second hardware implemented server], a value associated with an action ([0015], “"feedback" about his own performance.”; a time at high speeds and/or with regard to lane-changing processes and/or or steering behavior at high speeds. [0021]) performed by the vehicle (The motor vehicle itself therefore uses the driving activity of the driver in various driving situations to assess the driving ability of the driver and thus gives him, so to speak, "feedback" about his own performance. Consequently, for the continuous monitoring of the driving activity, measurement data describing the driving behavior of the driver are recorded and evaluated, for example by comparison with reference values and/or permitted intervals. This evaluation gives an indication of how the driver has behaved in the current, examined driving situation and thus of his driving ability. [0015]; examiner notes that the driver is being constantly monitored during their current driving session ("vehicle event")) during the event (the continuous monitoring of the driving activity [0015]);
Russo does not explicitly teach, however Jorn teaches:
sending, by the [second] hardware-implemented server (provision can be made on a voluntary basis for the evaluation value determined by motor vehicle 1 to be transmitted to an external device 19, where further evaluation is carried out centrally, so that evaluation values from drivers of different vehicles can also be examined there. [0053]; It is therefore conceivable, for example, that the evaluation value - possibly together with other information - can be transmitted to a driver's home computer [0031 ]), the user status (It is therefore proposed to provide the motor vehicle with information that provides information about the driving ability of the current driver. [0008]) to the vehicle to permit the user to access a first set of features of the vehicle (Viewed from a safety perspective, this means that driving functions and performance features may not yet be available to the driver, so that incorrect reactions and undesired driving states can be avoided. [0008]);
whether to modify the user status (For example, some driving functions and performance features can be activated less for the novice driver, but low threshold values for an automatic driving intervention can be provided, while an experienced driver can gain access to the entire range of services. Any possibilities are conceivable here. [0011]; examiner notes that the user has a score and proficiency level assigned to them ( e.g. "novice driver") which then corresponds to a series of functions of the vehicle that is available to the driver, which is the "vehicle status".) by changing a number of features of the first set of features that can be accessed by the user (by increasing or decreasing a number of features that may be operated by the user [0011])
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo to include the teachings as taught by Jorn to provide “a method for controlling a motor vehicle, in a particular driving functions, which enables operations of the motor vehicle to be better adapted to the individual driver” [Jorn, 0006].
Russo in view of Jorn does not explicitly teach, however Purgatorio teaches:
a first hardware-implemented server (fig. 1, computing device 100; fig. 2, the server-side computing device 100a)
having a user status linked (one or more of the application servers 205 may be configured to provide a service that receives telematics data from users and converts the telematics data into safe driving currency that may be used in various video games and/or with one or more other entities [col 10, lines 42-46]) to a second hardware-implemented server (fig. 2, application servers 205, servers 211) that is different than the first hardware-implemented server (fig. 1, computing device 100; fig. 2, the server-side computing device 100a);
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo and Jorn to include the teachings as taught by Purgatorio to provide systems and methods for awarding drivers electronic safe driving currency (e.g., driving points) for safe operation of a vehicle for use in purchasing electronic and real-world user-selectable benefits; systems and methods for discovering establishments along a user's route at which a driver may purchase such benefits; systems and methods for obtaining safe driving currency by winning safe driving tournaments; systems and methods for obtaining a driving score of a public transport as a rider approaches the public transport; and systems and methods for using gaming behavior to determine an insurance premium [Purgatorio, abstract].
Krishna also teaches:
having a user status linked to a second hardware-implemented server (fig. 2, onboard detection device 110) that is different than the first hardware-implemented server (fig. 2, cloud server 118);
Russo in view of Jorn and Purgatorio does not explicitly teach, however Krishna teaches:
receiving, by the first hardware-implemented server (fig. 2, on-board detection device 110, steps 215-225) and the second hardware-implemented server (fig. 2, cloud server 118, steps 230 and 235), a value associated with an action performed by the vehicle during the event (At 215, on-board detection device 110 facilitates recording of media data and multisensory data during a trip of a vehicle. A plurality of cameras mounted on the vehicle are used to record the media data which comprises of audio and visual data of a driving scene and a plurality of sensors positioned in the vehicle are used to record multisensory data such as, but not limited to, the speed, the acceleration force, location, the deceleration force etc. The media data may comprise a plurality of image frames and the sensory data may comprise of values recorded by the sensors and some graphs and traces. [0067]; At 230, the on-board detection device 110 is configured to send the metadata related to the detected event to a cloud server 118. In one embodiment, the metadata may comprise data such as the time and date of occurrence of the event, location of occurrence, an image frame from the plurality of image frames. In some embodiments, the image frame received in the metadata may depict most important image for determining the event occurrence. [0070]); and
based on a combination (fig. 2, step 255 requires both step 225 and step 245 to occur and baes the performance based upon the combination of those results.) of a first output from the first hardware-implemented server (fig. 2, step 225) and a second output from the second hardware-implemented server (Further at 245, the cloud server 118 is configured to verify or auto-review all the events that were previously detected by the on-board detection device. The method of verifying all the detected events received by the on-board detection device is termed as ‘Auto Review’. The verification of the detected events may be done after each trip and in some embodiments, the verification may be done on-demand based on a request received from a driver through on-board detection device. [0073]), determining whether to modify the user status by changing a number of features of the first set of features that can be accessed by the user (At 255, the cloud server 118 is configured to calculate a performance score of the driver 108. The performance score of the driver 108 is calculated after each trip based on a number of detected events, weight coefficients corresponding to the number of detected events and a total distance travelled by the driver in the trip. [0075]) based on a first threshold range used by the first hardware-implemented server (At 225, the on-board detection device 110 is configured to detect an event occurrence based on the generated metadata and the set of configuration parameters received from the fleet manager device. For example, if the threshold for a speed violation in the set of configuration parameters is 70 Kmph and the driver has crossed the limit and has driven the vehicle in 80 Kmph, the on-board detection device 110 detects an event of speed violation based on the generated metadata in real time. [0069]) and a second threshold range used by the second hardware-implemented server (Further at 245, the cloud server 118 is configured to verify or auto-review all the events that were previously detected by the on-board detection device. The method of verifying all the detected events received by the on-board detection device is termed as ‘Auto Review’. The verification of the detected events may be done after each trip and in some embodiments, the verification may be done on-demand based on a request received from a driver through on-board detection device. [0073]; At the vehicle side, it is not convenient to use complex algorithms for event detection, as a result, there is a high probability of false event detection at the on-board detection device. To overcome this problem, the cloud server verifies detection of the detected event by utilizing computationally complex event detection and sophisticated algorithms for reliable detection. More specifically, the cloud server may utilize computer vision, machine learning and artificial intelligence techniques for detecting objects/events of interest and ensures compliance. [0035])
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo in view of Jorn and Purgatorio to include the teachings as taught by Krishna because “the same configuration parameters are also sent to the cloud server 118. The cloud server 118 is used to verify the detected events using more sophisticated algorithms in order to auto-review the detected events. In one embodiment, at the start of every trip, and during every trip at certain intervals, the fleet manager device polls configuration settings on the cloud server to ensure that the correct compliance numbers and metrics are enforced [Krishna, 0066]”.
Regarding claim 16:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 15, upon which this claim is dependent.
Russo further teaches:
wherein the action is identified by a sensor of the vehicle (a vehicle head unit to receive the vehicle data from sensors at the head unit [0028]),
Regarding claim 17:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 15, upon which this claim is dependent.
Russo further teaches:
comparing the action to a set of predetermined vehicle actions to determine the value (the client device 10 transmits raw vehicle data to the driver performance analysis server 58, and the driver performance analysis server 58 may compare the raw vehicle data to a braking, speeding, acceleration, or maneuvering threshold to identify an unsafe driving event. [0042]);
identifying that the value is within the first threshold range (when the braking score is between 70 and 89, the braking score counts toward the star level score but does not count toward the shield level score [0045]) and the second threshold range (When the braking score is above 90, the braking score counts toward both the star level and the shield level scores [0045]);
Jorn further teaches:
comparing the action to a set of predetermined vehicle actions to determine the value (The information from these sensors and driver assistance systems is combined and evaluated in order, for example, to identify a driving situation and the driving behavior of the driver in the driving situation and then to evaluate them, for example by comparing them with threshold values or intervals. [0020]);
identifying that the value is within the first threshold range (Provision can be made for specific configurations of performance features and/or driving functions and/or threshold values to be assigned to specific values and/or value ranges for the evaluation value. [0011]) and the second threshold range (examiner notes that using both servers to make the same calculation is simply a supplication of parts to provide the expected benefit of data validation and comparison that is shown as a known benefit by at least Krishna as shown below. See MPEP 2144.04(VI)(B).);
and increasing the user status (The evaluation value is then determined accordingly, for example increased by a certain number of points. [0020]) to an increased user status in response to the value being within the first threshold range and the second threshold range (The data from a wide variety of sensors and systems can be taken into account, for example acceleration sensors, steering angle sensors, environment sensors such as radar sensors, ultrasonic sensors, optical sensors and the like. The information from these sensors and driver assistance systems is combined and evaluated in order, for example, to identify a driving situation and the driving behavior of the driver in the driving situation and then to evaluate them, for example by comparing them with threshold values or intervals. [0020]).
Krishna further teaches:
identifying that the value is within the first threshold range (At 225, the on-board detection device 110 is configured to detect an event occurrence based on the generated metadata and the set of configuration parameters received from the fleet manager device. For example, if the threshold for a speed violation in the set of configuration parameters is 70 Kmph and the driver has crossed the limit and has driven the vehicle in 80 Kmph, the on-board detection device 110 detects an event of speed violation based on the generated metadata in real time. [0069]) and the second threshold range (Further at 245, the cloud server 118 is configured to verify or auto-review all the events that were previously detected by the on-board detection device. The method of verifying all the detected events received by the on-board detection device is termed as ‘Auto Review’. The verification of the detected events may be done after each trip and in some embodiments, the verification may be done on-demand based on a request received from a driver through on-board detection device. [0073]; At the vehicle side, it is not convenient to use complex algorithms for event detection, as a result, there is a high probability of false event detection at the on-board detection device. To overcome this problem, the cloud server verifies detection of the detected event by utilizing computationally complex event detection and sophisticated algorithms for reliable detection. More specifically, the cloud server may utilize computer vision, machine learning and artificial intelligence techniques for detecting objects/events of interest and ensures compliance. [0035]);
Regarding claim 18:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 17, upon which this claim is dependent.
Jorn further teaches:
sending the increased user status to the vehicle to control the vehicle to permit the user access to a second set of vehicle features (This also applies to the example of novice drivers, who can drive highly powered vehicles and, over time, gain incremental access to features and driving functions that require higher driving skills. [0010]; some driving functions and performance features can be activated less for the novice driver, but low threshold values for an automatic driving intervention can be provided, while an experienced driver can gain access to the entire range of services. Any possibilities are conceivable here. [0011]) that were not accessible under the user status (while an experienced driver can gain access to the entire range of services [0011]).
Regarding claim 20:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 17, upon which this claim is dependent.
Jorn further teaches:
and update a user profile (The evaluation value related to all journeys by a driver with the motor vehicle is expediently stored, which means it is continued over several journeys. [0015]) with the increased user status (This evaluation gives an indication of how the driver has behaved in the current, examined driving situation and thus of his driving ability. Evaluations of several such situations, which can be mapped, for example, via a situation value, in particular a score achieved, are then included in the update of the evaluation value [0015]).
Claims 5, 7, 12, 14, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Russo et. al. (US 2023/0132673), herein Russo in view of Jorn et. al. (DE 102009039774), herein “Jorn”, Purgatorio et. al. (US PAT NO 10,885,539) (herein “Purgatorio”) and Krishna A G (US 2020/0079387), herein “Krishna” in further view of Bryant et. al. (US PAT NO 10,929,931) (herein “Bryant”)).
Regarding claim 5:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 1, upon which this claim is dependent.
Jorn further teaches:
a plurality of vehicle statuses associated with corresponding sets of vehicle features (the identification of the driver can be linked to a general profile of the driver containing, for example, his/her preferred settings with regard to the seat, controls, steering wheel, displays and the like, which can be used as well as the evaluation value. [0013]; it should be noted in this context that when several evaluation values are used, these can also be evaluated to form at least one further evaluation value, for example in relation to a specific driving function and/or a specific performance feature and/or a threshold value for an automatic driver intervention. [0017]; The evaluation value 12 is driver-specific, it reflects the driving ability of the current driver and can of course be stored for further trips or even transferred to another motor vehicle, whereby an adjustment can be made if necessary, for example a reduction if the other motor vehicle has a higher motor or similar. [0045]);
Russo in view of Jorn, Purgatorio, and Krishna does not explicitly teach, however Bryant teaches:
retrieving, by the first hardware-implemented server (configuring or implementing a plurality of servers, each of the plurality of servers maintaining a copy of a distributed ledger [col 1, lines 62-64]) or the second hardware-implemented server (configuring or implementing a plurality of servers, each of the plurality of servers maintaining a copy of a distributed ledger [col 1, lines 62-64]), a smart contract (In one embodiment, one or more transactions 202 or events may relate to: smart contracts [col 7, lines 57-58]) from a blockchain (the node 102 may use the blockchain manager 414 in conjunction with the smart contracts 416 stored in memory 404 to execute the functionality disclosed herein. [col 8, lines 58-61]);
wherein the smart contract (“The smart contracts may relate to”) specifies a plurality of vehicle statuses associated with corresponding sets of vehicle features (The smart contracts may relate to, or be associated with, insureds and/or insured assets, including smart insurance contracts, smart maintenance contracts, smart health care contracts, smart repair or upkeep contracts, etc. [col 9, lines 1-4]);
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo in view of Jorn, Purgatorio, and Krishna to include the teachings as taught by Bryant because “unlike a traditional system which may use a central authority, a single party cannot unilaterally alter the distributed ledger. This inability to modify past transactions lead to blockchains being generally described as trusted, secure, and immutable. [Bryant, col 4, lines 3-7]”. Examiner also notes that the combination of Jorn and Bryant is obvious because it is applying a known technique to a known device ready for improvement to yield predictable results. Jorn discloses a driver evaluation method that is able to grant access to features based on the skill of the driver. This information is saved in a server or locally on the vehicle to be applied at a later time or on different vehicles. Jorn does not disclose storing the data in a smart contract stored in a blockchain. However, Bryant discloses storing different vehicle data in a smart contract in a blockchain. Because Bryant discloses the benefits of the blockchain being a more secure and immutable place to store data, one would be motivated and recognized the ability to store any vehicle data in a smart contract in a blockchain. Therefore this would have been an easily recognized and predictable result.
Regarding claim 7:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 1, upon which this claim is dependent.
Jorn further teaches:
comprising the modified user status (This evaluation gives an indication of how the driver has behaved in the current, examined driving situation and thus of his driving ability. [0015]; The evaluation value 12 is driver-specific, it reflects the driving ability of the current driver and can of course be stored for further trips or even transferred to another motor vehicle, whereby an adjustment can be made if necessary, for example a reduction if the other motor vehicle has a higher motor or similar. [0045]);
Russo in view of Jorn, Purgatorio, and Krishna does not explicitly teach, however Bryant teaches:
creating a blockchain transaction comprising the modified user status (fig. 7, step 710);
and storing the blockchain transaction in a blockchain (fig. 7, step 716).
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo in view of Jorn, Purgatorio, and Krishna to include the teachings as taught by Bryant because “unlike a traditional system which may use a central authority, a single party cannot unilaterally alter the distributed ledger. This inability to modify past transactions lead to blockchains being generally described as trusted, secure, and immutable. [Bryant, col 4, lines 3-7]”. Examiner also notes that the combination of Jorn and Bryant is obvious because it is applying a known technique to a known device ready for improvement to yield predictable results. Jorn discloses a driver evaluation method that is able to grant access to features based on the skill of the driver. This information is saved in a server or locally on the vehicle to be applied at a later time or on different vehicles. Jorn does not disclose storing the data in a smart contract stored in a blockchain. However, Bryant discloses storing different vehicle data in a smart contract in a blockchain. Because Bryant discloses the benefits of the blockchain being a more secure and immutable place to store data, one would be motivated and recognized the ability to store any vehicle data in a smart contract in a blockchain. Therefore this would have been an easily recognized and predictable result.
Regarding claim 12:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 8, upon which this claim is dependent.
Jorn further teaches:
a plurality of vehicle statuses associated with corresponding sets of vehicle features (the identification of the driver can be linked to a general profile of the driver containing, for example, his/her preferred settings with regard to the seat, controls, steering wheel, displays and the like, which can be used as well as the evaluation value. [0013]; it should be noted in this context that when several evaluation values are used, these can also be evaluated to form at least one further evaluation value, for example in relation to a specific driving function and/or a specific performance feature and/or a threshold value for an automatic driver intervention. [0017]; The evaluation value 12 is driver-specific, it reflects the driving ability of the current driver and can of course be stored for further trips or even transferred to another motor vehicle, whereby an adjustment can be made if necessary, for example a reduction if the other motor vehicle has a higher motor or similar. [0045]);
Russo in view of Jorn, Purgatorio, and Krishna does not explicitly teach, however Bryant teaches:
retrieve a smart contract (In one embodiment, one or more transactions 202 or events may relate to: smart contracts [col 7, lines 57-58]) from a blockchain (the node 102 may use the blockchain manager 414 in conjunction with the smart contracts 416 stored in memory 404 to execute the functionality disclosed herein. [col 8, lines 58-61]);
wherein the smart contract specifies (“The smart contracts may relate to”), a plurality of vehicle statuses associated with corresponding sets of vehicle features (The smart contracts may relate to, or be associated with, insureds and/or insured assets, including smart insurance contracts, smart maintenance contracts, smart health care contracts, smart repair or upkeep contracts, etc. [col 9, lines 1-4]);
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo in view of Jorn, Purgatorio, and Krishna to include the teachings as taught by Bryant because “unlike a traditional system which may use a central authority, a single party cannot unilaterally alter the distributed ledger. This inability to modify past transactions lead to blockchains being generally described as trusted, secure, and immutable. [Bryant, col 4, lines 3-7]”. Examiner also notes that the combination of Jorn and Bryant is obvious because it is applying a known technique to a known device ready for improvement to yield predictable results. Jorn discloses a driver evaluation method that is able to grant access to features based on the skill of the driver. This information is saved in a server or locally on the vehicle to be applied at a later time or on different vehicles. Jorn does not disclose storing the data in a smart contract stored in a blockchain. However, Bryant discloses storing different vehicle data in a smart contract in a blockchain. Because Bryant discloses the benefits of the blockchain being a more secure and immutable place to store data, one would be motivated and recognized the ability to store any vehicle data in a smart contract in a blockchain. Therefore this would have been an easily recognized and predictable result.
Regarding claim 14:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 8, upon which this claim is dependent.
Jorn further teaches:
modified user status based on the user profile (This evaluation gives an indication of how the driver has behaved in the current, examined driving situation and thus of his driving ability. [0015]; The evaluation value 12 is driver-specific, it reflects the driving ability of the current driver and can of course be stored for further trips or even transferred to another motor vehicle, whereby an adjustment can be made if necessary, for example a reduction if the other motor vehicle has a higher motor or similar. [0045]);
Russo in view of Jorn, Purgatorio, and Krishna does not explicitly teach, however Bryant teaches:
create a blockchain transaction comprising the modified user status based on the user profile (fig. 7, step 710);
and store the blockchain transaction in a blockchain (fig. 7, step 716).
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo in view of Jorn, Purgatorio, and Krishna to include the teachings as taught by Bryant because “unlike a traditional system which may use a central authority, a single party cannot unilaterally alter the distributed ledger. This inability to modify past transactions lead to blockchains being generally described as trusted, secure, and immutable. [Bryant, col 4, lines 3-7]”. Examiner also notes that the combination of Jorn and Bryant is obvious because it is applying a known technique to a known device ready for improvement to yield predictable results. Jorn discloses a driver evaluation method that is able to grant access to features based on the skill of the driver. This information is saved in a server or locally on the vehicle to be applied at a later time or on different vehicles. Jorn does not disclose storing the data in a smart contract stored in a blockchain. However, Bryant discloses storing different vehicle data in a smart contract in a blockchain. Because Bryant discloses the benefits of the blockchain being a more secure and immutable place to store data, one would be motivated and recognized the ability to store any vehicle data in a smart contract in a blockchain. Therefore this would have been an easily recognized and predictable result.
Regarding claim 19:
Russo in view of Jorn, Purgatorio, and Krishna discloses all the limitations of claim 15, upon which this claim is dependent.
Jorn further teaches:
a plurality of vehicle statuses associated with corresponding sets of vehicle features (the identification of the driver can be linked to a general profile of the driver containing, for example, his/her preferred settings with regard to the seat, controls, steering wheel, displays and the like, which can be used as well as the evaluation value. [0013]; it should be noted in this context that when several evaluation values are used, these can also be evaluated to form at least one further evaluation value, for example in relation to a specific driving function and/or a specific performance feature and/or a threshold value for an automatic driver intervention. [0017]; The evaluation value 12 is driver-specific, it reflects the driving ability of the current driver and can of course be stored for further trips or even transferred to another motor vehicle, whereby an adjustment can be made if necessary, for example a reduction if the other motor vehicle has a higher motor or similar. [0045]);
Russo in view of Jorn, Purgatorio, and Krishna does not explicitly teach, however Bryant teaches:
retrieving a smart contract (In one embodiment, one or more transactions 202 or events may relate to: smart contracts [col 7, lines 57-58]) from a blockchain (the node 102 may use the blockchain manager 414 in conjunction with the smart contracts 416 stored in memory 404 to execute the functionality disclosed herein. [col 8, lines 58-61]);
wherein the smart contract specifies (“The smart contracts may relate to”), a plurality of vehicle statuses associated with corresponding sets of vehicle features (The smart contracts may relate to, or be associated with, insureds and/or insured assets, including smart insurance contracts, smart maintenance contracts, smart health care contracts, smart repair or upkeep contracts, etc. [col 9, lines 1-4]);
It would have been obvious to one of ordinary skill in the art at the time of filing to have modified Russo in view of Jorn, Purgatorio, and Krishna to include the teachings as taught by Bryant because “unlike a traditional system which may use a central authority, a single party cannot unilaterally alter the distributed ledger. This inability to modify past transactions lead to blockchains being generally described as trusted, secure, and immutable. [Bryant, col 4, lines 3-7]”. Examiner also notes that the combination of Jorn and Bryant is obvious because it is applying a known technique to a known device ready for improvement to yield predictable results. Jorn discloses a driver evaluation method that is able to grant access to features based on the skill of the driver. This information is saved in a server or locally on the vehicle to be applied at a later time or on different vehicles. Jorn does not disclose storing the data in a smart contract stored in a blockchain. However, Bryant discloses storing different vehicle data in a smart contract in a blockchain. Because Bryant discloses the benefits of the blockchain being a more secure and immutable place to store data, one would be motivated and recognized the ability to store any vehicle data in a smart contract in a blockchain. Therefore this would have been an easily recognized and predictable result.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 Scott R Jagolinzer whose telephone number is (571)272-4180. The examiner can normally be reached M-Th 8AM - 4PM Eastern.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christian Chace can be reached at (571)272-4190. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Scott R. Jagolinzer
Examiner
Art Unit 3665
/S.R.J./Examiner, Art Unit 3665 /CHRISTIAN CHACE/Supervisory Patent Examiner, Art Unit 3665